Hi devs,
To implement the above functionality I have created the following UI:
http://i43.tinypic.com/28l7x2u.png which was dervied from the mockups
located at
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/ImportCompositeDocument
Descriptions of various fields are as follows:
* Document - The office document to be uploaded (and imported)
* Style filtering - Whether to filter office styles or not
* Heading level to split - If the user wishes to split the imported document
into multiple wiki pages, he has to select the heading level (h1, h2, h3...
h6) to be used when splitting the document. If the user does not select a
heading level, the document will be imported as it is (no splitting).
* Custom split regex - If the user wants to further refine the split
criterion (based on the content of header) this field allows him to specify
that criterion through a regular expression.
Example regular expression: <b>Section<b>.*
Open Question: Aren't regular expressions bit too technical for users?
* Target space - This is where the resulting document(s) will land.
* Target (master) page - The main document holding the TOC (in case of
splitting), otherwise this is the name of resulting wiki page.
* Child pages naming method - If the document is split into multiple pages,
pages should be named according to some criterion. This combo box allows
users to specify that criterion.
Regarding the implementation, we have two possible approaches.
1. Implement the splitting in w3c dom level (xhtml)
2. Implement the splitting in XDOM level
* In the first approach we will navigate through the child elements directly
under <body> tag and find matching heading elements. For the regex, we will
have to serialize the heading element so that the regex can be evaluated.
Heading elements can be serialized as explained here:
http://forums.sun.com/thread.jspa?threadID=698475
* In the second approach we can either use XDOM operations or use a
SplittingChainingListener. But I don't know whether regex matching is
possible with this scheme.
Also, regardless of the method we follow, there will be a problem with large
office documents (say 100MB or so). Loading such a file into memory (dom or
xdom) would not be a good idea.
I haven't decided which method to go with yet. So it will be really great if
we can sort this out as soon as possible.
Thanks.
- Asiri
Norguir Bellagio wrote:
> Hi,
>
> I have crawled the mailing lists and support forums on this but I am
> unable to figure out the answer.
>
> I am evaluating Xwiki and love Workspaces from what I've seen so far.
> The one thing that really bogs me down is the inability to register an
> authenticated SMTP server. I have read there is a patch from Liliane,
> and the feature is included on 1.6 but I just can't seem to understand
> how to get is to work. In an evaluation perspective (and very much so as
> well in production), not being able to use authenticated SMTP server is
> a no go for me.
> Could you please point me to a resource that clarifies what the
> situation is and possibly, the steps to enable it on 1.7.
>
> Thanks !
>
> norguir
Actually I'm still waiting for it :/
I just made a quick check and it looks like that patch was not
committed, there's no support for setting username and password in
Administration, and registration mails still go via deprecated
XWiki.sendMessage, which is using Apache Commons SMTPClient (made
obsolete by JavaMail ages ago) and has no support for username/password
and extra properties.
As for mail.smtp.starttls.enable=true, AFAIK when used alone it simply
does not make sense.
_Please_ do something about it :/
If I remember correctly last time the main issue was that the code had
to be integrated in core instead of mail plugin, please, can't we have
the thing working at all first, worry about module separation later?
Basic mail support _is_ core functionality. For me it's a showstopper,
and I don't have enough time to maintain a private fork, either smtp
auth goes in, or I'm going out :/
And before someone says it's open source and I should stop bitching and
submit a patch - I _did_ submit a patch months ago :/
Greetings, Lilianne
Hi Sergiu,
> Since you only committed in the trunk, should this be @since 1.9M1? The
> same for all the other @since tags.
Merged with 1.8 branch today.
> This is good for a standalone Java program. When it comes to webapps,
> the lifecycle is much more complex, since a webapp can be stopped and
> reloaded at will, in a clustered environment it can be moved from one
> computer to another, or it can even be stopped from within the
> application itself. This code is good for the moment, but it will have
> to be changed as soon as we introduce lifecycle events in the
> observation component.
>
I agree :)
Creating the bridge for each new context is a waste of CPU and RAM.
> Since the bridge is stateless, it can be a member initialized in the
> constructor.
>
> > + context.put(VELOCITY_CONTEXT_KEY, new
> OpenOfficeServerManagerVelocityBridge(oomanager, docBridge));
> > + }
> > +}
> >
>
Fixed.
> Why not override toString()?
>
> > + public String getDescription()
> > + {
> > + return this.stateDescription;
> > + }
> > + }
>
Fixed.
>
> in in
>
> > + * These configuration properties are defined in in XWiki's global
> configuration file using the prefix of
> > + * "officeimporter".
> > + * </p>
> > + *
> > + * @version $Id$
> > + * @since 1.8RC3
> > + */
> > +public interface OpenOfficeServerConfiguration
>
Fixed.
> I'm not sure that checking for specific values is a good decision.
> Perhaps checking for non-null, non-empty and non-negative?
>
> > +
> assertEquals(OfficeUtils.getDefaultOfficeHome().getAbsolutePath(),
> configuration.getHomePath());
> > +
> assertEquals(OfficeUtils.getDefaultProfileDir().getAbsolutePath(),
> configuration.getProfilePath());
> > + assertEquals(50, configuration.getMaxTasksPerProcess());
> > + assertEquals(30000, configuration.getTaskExecutionTimeout());
> > + }
> > +}
>
Fixed.
> Is this attachment used anywhere?
>
> > +<attachment>
> > +<filename>icon.png</filename>
> > +<filesize>8674</filesize>
> > +<author>XWiki.Admin</author>
> > +<date>1236277246000</date>
> > +<version>1.0</version>
> > +<comment></comment>
> > +</attachment>
>
Yes, it's used as the openoffice server administration icon in
XWikiPreferences page. This icon will be replaced by a better one (I have
asked laurent).
> I usually delete the tag objects from the XML file before committing.
>
Fixed (Removed tag objects)
> > +#if($hasAdmin)
> > + #info($msgConfiguration)
> > + #if($request.action && $request.action=="stop")
>
> This is best done like this:
> #if("$!request.action" == 'stop')
>
> > + #if(!$oomanager.stopServer())
> > + #error($oomanager.lastErrorMessage)
> > + #end
> > + #elseif($request.action && $request.action=="start")
> > + #if(!$oomanager.startServer())
> > + #error($oomanager.lastErrorMessage)
> > + #end
> > + #elseif($request.action && $request.action=="restart")
>
> Since you're using it several times, you could store the action in a
> variable at the top:
> #set($currentAction = "$!request.action")
>
Fixed (learnt about $! just now)
> What's with the paragraphs? IMO they aren't needed, just write:
>
> $msgServerPath | $serverPath
>
> > +<p>$msgServerPath</p>|<p>$serverPath</p>
> > +<p>$msgServerProfile</p>|<p>$serverProfile</p>
> > +<p>$msgServerState</p>|<p>$currentState</p>
>
Well, without the paragraphs the table looks bit too tight.
>
> Better:
>
> Setting for the OpenOffice instance controlled by the office importer
> plugin.
>
> > +# OpenOffice
> >
> +#-------------------------------------------------------------------------------------
> > +
>
Fixed.
>
> Since 1.9M1?
>
> > +#-# [Since 1.8RC3]
> > +#-# Path to openoffice installation.
> > +# openoffice.homePath=/opt/openoffice.org3/
> > +
> > +#-# [Since 1.8RC3]
> > +#-# Path to openoffice execution profile.
>
> Is this right? For me it's /home/user/.ooo3/
>
> > +# openoffice.profilePath=/home/user/.openoffice.org/3
>
This is the default path structure returned by jodconverter. I think this is
valid for most Linux systems.
Thanks.
- Asiri
Hi,
Some time ago we agreed that component implementations should be
located in the internal package. I now believe it's wrong if we want
to allow users to use our modules separately from the rest of XWiki as
standard java beans. I think it's a good property to have that users
can integrate our modules into their own code without taking the whole
of XWiki. This is what I'm trying to do with the rendering module.
Thus I'm proposing to move the components out of the internal module
*only* for the rendering module for now even though I suspect that
we'll want to do that for all modules eventually.
Here's my +1
Thanks
-Vincent
Hi devs,
We have to make a decision about that.
So here are the proposals:
1) remove the block leading and trainling spaces
* The main goal is to make source formatting for tables for example
more readable
2) make the spaces inside paragraph non meaningfull
* Meaning an HTML like behavior where multiple spaces give one space
3) in case of 1) or 2) use ~<space> as non breaking space
WDYT ?
+0,5 for 1) it's not critical for me but i'm not against it and we
already decided to remove space before list item, headers etc.
-0 for 2) I don't see the need for that and it's a lot easier for the
parser to make spaces meaningfull (what to do when you have "test **
bold**" and things like that)
+1 for 3)
On Sat, Feb 28, 2009 at 15:44, Vincent Massol <vincent(a)massol.net> wrote:
> Hi,
>
> This is our last chance to change this behavior. We've found several
> places where having meaningful spaces are counter-productive:
>
> * in table cells since we can't align table anymore. For example:
>
> |= column1 |= column2
> | this is some para | second column
> | hello | world
>
> (not sure this will be rendered nicely in mail but you see what I mean)
>
> * in scripts since having meaningful spaces prevents us from aligning
> velocity or groovy scripts. For ex we can't write:
>
> #if (....)
> #if (...)
> do something
> # end
> #end
>
> To see a better example have a look at http://tinyurl.com/ahz669
>
> What I think users real want are meaningful new lines but I see cons
> overweighting pros for having meaningful white spaces. Thus I'm think
> we should strip whitespaces at beginning and end of lines including
> for line breaks.
> I'm slightly less sure for multiple spaces between words but even
> there I think we could strip them have users use {{{ }}} to put a non
> breaking space for ex (or introduce a {{space/}} macro or another
> special syntax although I'd rather we don't introduce a new syntax).
>
> WDYT?
>
> Thanks
> -Vincent
> http://xwiki.com
> http://xwiki.org
> http://massol.net
>
>
>
>
>
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
http://jira.xwiki.org/jira/browse/XE-391
I believe this issue occurs when there is only one initial revision to a
> document, and 'history' is selected and attempts to diff between version 1
> (which exists) and version 2 (which doesn't).
>
> The code needs to be special-cased for this
> http://en.wikipedia.org/wiki/Off-by-one_error#Fencepost_error
>
> Here's some recent examples, caused by search engines:
>
> 2009-03-03 14:44:16,472 [/xwiki/bin/view/XWiki/SchedulerJobClass?viewer=changes&rev1=$%7Brev1%7D&rev2=$%7Brev2%7D] [TP-Processor35] ERROR api.XWiki - Failed to read versioned document
> org.suigeneris.jrcs.rcs.InvalidVersionNumberException: ${rev1}
> at org.suigeneris.jrcs.rcs.Version.<init>(Version.java:120)
>
> What's with scheduler job class? one revision:
>
> History of SchedulerJobClass
> Version Editor Date Comment
> 1.1 NielsMayer.com Administrator Dec 15, 2006 03:45:59 GMT-08:00
>
> Another:
>
> 2009-03-07 03:24:39,164 /xwiki/bin/view/XWiki/WebPreferences?viewer=changes&rev1=$%7Brev1%7D&rev2=$%7Brev2%7D] [TP-Processor6] ERROR api.XWiki - Failed to read versioned document
> org.suigeneris.jrcs.rcs.InvalidVersionNumberException: ${rev2}
> at org.suigeneris.jrcs.rcs.Version.<init>(Version.java:120)
>
> What's with WebPreferences? One revision:
>
> Version Editor Date Comment
> 1.1 NielsMayer.com Administrator Apr 20, 2007 09:17:52 GMT-08:00
>
> [ Show » <http://jira.xwiki.org/jira/browse/XE-391> ]
Niels Mayer, http://nielsmayer.com<http://jira.xwiki.org/jira/secure/ViewProfile.jspa?name=nielsmayer>added
a comment - 08/Mar/09
19:04 - edited I believe this issue occurs when there is only one initial
revision to a document, and 'history' is selected and attempts to diff
between version 1 (which exists) and version 2 (which doesn't). The code
needs to be special-cased for this
http://en.wikipedia.org/wiki/Off-by-one_error#Fencepost_error Here's some
recent examples, caused by search engines:
2009-03-03 14:44:16,472
[/xwiki/bin/view/XWiki/SchedulerJobClass?viewer=changes&rev1=$%7Brev1%7D&rev2=$%7Brev2%7D]
[TP-Processor35] ERROR api.XWiki - Failed to
read versioned document
org.suigeneris.jrcs.rcs.InvalidVersionNumberException: ${rev1}
at org.suigeneris.jrcs.rcs.Version.<init>(Version.java:120)
What's with scheduler job class? one revision:
History of SchedulerJobClass
Version Editor Date Comment
1.1 NielsMayer.com Administrator Dec 15, 2006 03:45:59 GMT-08:00
Another:
2009-03-07 03:24:39,164
/xwiki/bin/view/XWiki/WebPreferences?viewer=changes&rev1=$%7Brev1%7D&rev2=$%7Brev2%7D]
[TP-Processor6] ERROR api.XWiki - Failed to read
versioned document
org.suigeneris.jrcs.rcs.InvalidVersionNumberException: ${rev2}
at org.suigeneris.jrcs.rcs.Version.<init>(Version.java:120)
What's with WebPreferences? One revision:
Version Editor Date Comment
1.1 NielsMayer.com Administrator Apr 20, 2007 09:17:52 GMT-08:00
Niels
http://nielsmayer.com
I've improved slightly the translation app at http://l10n.xwiki.org
It now supports sorting per the translation keys both for the output
(the file will be nicer looking) and when translating, which will make
it easier to translate keys that correspond to the same module together.
In terms of status the great news is that we have the following language
completed:
- English (obviously)
- French
- German
- Romanian
Translators might want to have a look at the "outdated" translations.
These are the already translated keys that have in the mean time changed
in the english language.
Outdated translations are available from the OutDated link of your language.
Review is also important. It gives a second chance to check
translations. Also an already translated key that has been changed and
not reviewed will not be taken into account until it is reviewed.
Review is accessible from the Review link of your language.
In any case I'm really happy with what we have achieve. We now have 4
complete languages and we can keep track of the changes.
We'll make sure this hard work is going to make it in 1.8 final release.
Thanks to all for the contribution and we welcome other volunteers to
tackle the other languages.
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi devs,
Someone on the list asked how create a link and an image pointing to a
relative reference (that he got using one of XWiki's API since they
all return relative URL). We currently don't have a good solution for
this and I'd like to propose a solution.
For links
=======
Make the usage of a prefix that specifies what comes next a generic
feature. We have the following needs:
* link to a URL
* link to a relative path
* link to a document
* link to a mailto
* link to an attachment
I propose the following syntax:
[[label>>prefix:value]]
where prefix = one of http:, path:, doc:, mailto:, attach:
In addition I propose that when there's no prefix or if the prefix is
an unknown prefix then to consider that the reference is a reference
to a document (equivalent to doc:).
Pros:
* Generic
* Ability to add more prefixes later on (for ex ftp:)
* Ability to have virtual wikis which have "reserved" names such as
"doc", "http", "ftp", "mailto", etc since you can write
[[doc:doc:Space.Page]]
* Ability to write shorthand for documents in the text, such as: "This
is a link doc:Space.Page"
* Ability to reference relative paths and write stuff such as
{{velocity}}[[label>>path:$xwiki.getURL(something)]]{{/velocity}}
For images
=========
* Similar to links add the ability to add prefixes in a generic way.
We have the following needs:
* image where the source is at a URL
* image where the source is at a relative path
* image where the source is in a document
I propose the following syntax:
image:prefix:value
where prefix = one of http:, path:, attach:
Note that we already support image:http://... so the proposal here is
simply to make it generic.
In addition I propose that when there's no prefix or if the prefix is
unknown then to consider that the image is to be found in a document
(equivalent to attach:).
Same pros as above.
Here's my +1
WDYT?
Thanks
-Vincent
Hi,
I'm an Computer Science Undergraduate who is currently undergoing training
and engaged n the field of Open Source SOA products n development. I've
recently done project work in the area of WS Security (WS [Web Services]
Policy derivation from SOAP messages n some OSGI component implementatons
around that..) and have fair knowlege on WS security implementations. Also
also have an good understanding in Apache Axis2 Engine and been working on
Apache Axis2 Engine developing Ruby Services deployment using JRuby frame
work..
I would pretty much like to participate in a XWiki GSoc project for 2009 as
i see this as a great opportunity to expand my understanding in this field
and as a great learning experience. I had a look at previous 2008 xWiki
Gsoc Ideas,Devs list issues and some jiras and i gained interest in doing
some work in xWiki Core. I was particularly interested in ideas such as SAML
Authentication (Reported @ xWiki JIRA by Sergiu
Dumitriu<http://jira.xwiki.org/jira/browse/XWIKI-402>) , Support for
AJAX Calls (Reported @ xWiki JIRA by Sergiu
Dumitriu <http://jira.xwiki.org/jira/browse/XWIKI-641> ) , Xwiki Web
Services integration , and would like to know whether aforementioned work
(/proposals) are still available. However i would also be open to any other
ideas that will be put forward by XWiki org and would like to hear about
that too.
BTW i still don't know whether this is too early or not to ask for project
ideas n stuff ,but am certainly hoping to work with you guys if all goes
well .I'm still new to XWiki engine and it's aspects but i am willing to,
learn and have a good run on xWiki. Your feedback regarding this is very
much appreciated..Thnx in advance
.
Regards,
Udayanga Shaminda Wickramasinghe