7 Jul
2008
7 Jul
'08
10:03 a.m.
Hi Vincent & all,
I finish the clean of the plugin code and write a simple user manual. You
can see it in
http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter#HQuickStart. All
files needed for this plugin can be found in that page
http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter, except the
openoffice install .
Please give some feedback after try the plugin. Any feedback will be very
appreciated.
This plugin is very initial. It only put out the html code , not xwiki
syntax, because the html code to xwiki syntax conversion should be done by
XHTMLParser which is not ready yet.
Open question:
Now the plugin can handle the file which is uploaded to xwiki as a
attachment. Do you think it's necessary that the office importer would have
the upload feature itself or should provide a XWikiAction something like
"bin/importer/Main/page"?
Now the plugin can work. However it's a little complicate. If you want to
convert a office document
1. you first upload the document
2. copy the attachment name(because the name of document change after
upload)
3. edit the page and add the velocity code to use the importer plugin
4. save and view.
I think it should be more simple.
WDYT
--
Sincerely,
Wang Ning
7 Jul
7 Jul
11:27 a.m.
Hi Wang,
[snip]
I'm looking forward testing your work !
Now the plugin can work. However it's a little
complicate. If you want to
convert a office document
1. you first upload the document
2. copy the attachment name(because the name of document change after
upload)
3. edit the page and add the velocity code to use the importer plugin
4. save and view.
I think it should be more simple.
So do I :-)
There is 2 ways we can go about doing this : the page action way and the
application way.
1. Page action : we add an "import" action in the menu at the top of the
page (and maybe in the WYSIWYG editor as well). When clicking on the button,
the user is prompted to choose a compatible file on his machine, then he
clicks on "import" (with an interface similar to the one used for uploading
attachments). The .../bin/import/Main/... is called, and the content from
the file appended at the bottom of the existing page, with a #info('') macro
at the top saying something like "The following content has been imported to
the page :"
2. Application : we create an OfficeImport application with the following
components : a homepage where the user is prompted to import one or multiple
documents. The documents are then imported, each creting its own wiki page.
Once the importation is complete, the user is prompted to move the documents
to their new locations (using the Rename or the copy feature to implement
this)
The benefits of going the page way is that it's probably more intuitive for
users. However it means adding core changes = less flexibility in the long
run. And the action bar already has a lot of items ;-)
OTOH going the application way woud make the application easier to setup
(plugin + XAR), store all the pages in a dedicated place and make it
possible to import many documents at once and sort things out at a later
stage. However it makes it a bit longer to import a file to a given page and
might be less intuitive...
WDYT ?
Guillaume
5:11 p.m.
On Mon, Jul 7, 2008 at 5:27 PM, Guillaume Lerouge <guillaume(a)xwiki.com>
wrote:
Hi Wang,
This action way is easy to implement as I can get whatever I want to use by
using java. But as you said, change the xwiki-core is not a good idea.
However, I can get the byte[] data of the source office doument without
using attachment.
[snip]
I'm looking forward testing your work !
Now the plugin can work. However it's a
little complicate. If you want to
convert a office document
1. you first upload the document
2. copy the attachment name(because the name of document change after
upload)
3. edit the page and add the velocity code to use the importer plugin
4. save and view.
I think it should be more simple.
So do I :-)
There is 2 ways we can go about doing this : the page action way and the
application way.
1. Page action : we add an "import" action in the menu at the top of the
page (and maybe in the WYSIWYG editor as well). When clicking on the
button,
the user is prompted to choose a compatible file on his machine, then he
clicks on "import" (with an interface similar to the one used for
uploading
attachments). The .../bin/import/Main/... is called, and the content from
the file appended at the bottom of the existing page, with a #info('')
macro
at the top saying something like "The following content has been imported
to
the page :"
2. Application : we create an OfficeImport application with the following
components : a homepage where the user is prompted to import one or
multiple
documents. The documents are then imported, each creting its own wiki
page.
Once the importation is complete, the user is prompted to move the
documents
to their new locations (using the Rename or the copy feature to implement
this)
The application way is good and decouple. However there are some problem
too. I want to get the name of the attachment after upload the office
document as the name of the document changed by the xwiki.clearName().
But the util.clearName() don't provide the same result. Do I need to add
another clearName model in api util? Alternately, I just provide a select
type input in the importer page which contain all the attachments in the
page for use to select the source attachments.
The benefits of going the page way is that it's probably more intuitive for
users. However it means adding core changes = less flexibility in the long
run. And the action bar already has a lot of items ;-)
OTOH going the application way woud make the application easier to setup
(plugin + XAR), store all the pages in a dedicated place and make it
possible to import many documents at once and sort things out at a later
stage. However it makes it a bit longer to import a file to a given page
and
might be less intuitive...
WDYT ?
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Sincerely,
Wang Ning
6:09 p.m.
Wang Ning wrote:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On Mon, Jul 7, 2008 at 5:27 PM, Guillaume Lerouge
<guillaume(a)xwiki.com>
wrote:
I don't think you need to go through the save as attachment at all..
You can use the FileUpload plugin...
http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-core/src…
which allows to retrive a file upload element withough saving it as an
attachment..
You retrieve it as a byte[]
Ludovic
Hi Wang,
This action way is easy to implement as I can get whatever I want to use by
using java. But as you said, change the xwiki-core is not a good idea.
However, I can get the byte[] data of the source office doument without
using attachment.
[snip]
I'm looking forward testing your work !
Now the plugin can work. However it's a
little complicate. If you want to
convert a office document
1. you first upload the document
2. copy the attachment name(because the name of document change after
upload)
3. edit the page and add the velocity code to use the importer plugin
4. save and view.
I think it should be more simple.
So do I :-)
There is 2 ways we can go about doing this : the page action way and the
application way.
1. Page action : we add an "import" action in the menu at the top of the
page (and maybe in the WYSIWYG editor as well). When clicking on the
button,
the user is prompted to choose a compatible file on his machine, then he
clicks on "import" (with an interface similar to the one used for
uploading
attachments). The .../bin/import/Main/... is called, and the content from
the file appended at the bottom of the existing page, with a #info('')
macro
at the top saying something like "The following content has been imported
to
the page :"
2. Application : we create an OfficeImport
application with the following
components : a homepage where the user is prompted to import one or
multiple
documents. The documents are then imported, each creting its own wiki
page.
Once the importation is complete, the user is prompted to move the
documents
to their new locations (using the Rename or the copy feature to implement
this)
The application way is good and decouple. However there are some problem
too. I want to get the name of the attachment after upload the office
document as the name of the document changed by the xwiki.clearName().
But the util.clearName() don't provide the same result. Do I need to add
another clearName model in api util? Alternately, I just provide a select
type input in the importer page which contain all the attachments in the
page for use to select the source attachments.
The benefits of going the page way is that
it's probably more intuitive for
users. However it means adding core changes = less flexibility in the long
run. And the action bar already has a lot of items ;-)
OTOH going the application way woud make the application easier to setup
(plugin + XAR), store all the pages in a dedicated place and make it
possible to import many documents at once and sort things out at a later
stage. However it makes it a bit longer to import a file to a given page
and
might be less intuitive...
WDYT ?
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8 Jul
8 Jul
10:33 a.m.
Wang Ning wrote:
This action way is easy to implement as I can get whatever I want to use by
using java. But as you said, change the xwiki-core is not a good idea.
However, I can get the byte[] data of the source office doument without
using attachment.
It is true that now it is hard to add new actions in the code, but in the future plugins
would be
able to provide their own actions, without changing the code. Still, the only changes
needed are:
- assigning a rights level, but the default one is "edit", which I think is a
good level for the
import action, so there's no need to change this
- registering the action in struts-config.xml, but that is not something hard to do; it is
on the
same level as registering the plugin in xwiki.cfg
You could simply get the name of the last attachment.
Personally, I'd go the action way. It is not as modular and easily-integrable as it
should, but in
the (1.7-1.8?) future this will change.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Now the plugin can work. However it's a little
complicate. If you want to
convert a office document
1. you first upload the document
2. copy the attachment name(because the name of document change after
upload)
3. edit the page and add the velocity code to use the importer plugin
4. save and view.
I think it should be more simple.
So do I :-)
There is 2 ways we can go about doing this : the page action way and the
application way.
1. Page action : we add an "import" action in the menu at the top of the
page (and maybe in the WYSIWYG editor as well). When clicking on the
button,
the user is prompted to choose a compatible file on his machine, then he
clicks on "import" (with an interface similar to the one used for
uploading
attachments). The .../bin/import/Main/... is called, and the content from
the file appended at the bottom of the existing page, with a #info('')
macro
at the top saying something like "The following content has been imported
to
the page :" 2.
Application : we create an OfficeImport application with the following
components : a homepage where the user is prompted to import one or
multiple
documents. The documents are then imported, each creting its own wiki
page.
Once the importation is complete, the user is prompted to move the
documents
to their new locations (using the Rename or the copy feature to implement
this)
The application way is good and decouple. However there are some problem
too. I want to get the name of the attachment after upload the office
document as the name of the document changed by the xwiki.clearName().
But the util.clearName() don't provide the same result. Do I need to add
another clearName model in api util? Alternately, I just provide a select
type input in the importer page which contain all the attachments in the
page for use to select the source attachments.
7 Jul
7 Jul
1:28 p.m.
Hi,
I've tested the importer.. Installation and running it went fine !
Pretty cool. The documents where well imported in HTML with images
attached and converted.
Some bugs:
- a documents with accents was showing the accents in UTF-8 when my
wiki is ISO-8869-1. A conversion needs to be done.
Some remarks:
- it would be nice that the application can launch OO itself
- you also need to write your code so that it can call the web service
version of jodconverter
- the application way would be nice to demonstrate and test the tool: a
file upload, you choose the page and the document is added at the end of
the page
- one of the features of the conversion should be to convert any OO to
HTML or PDF and should be integrated as links next to attachment (view
as HTML or view as PDF). Also there could be a macro to integrate the
HTML conversion in the middle of the page. Similar to {attach} but would
embed the document directly in the page. So you should make sure your
API allows to not only convert to wiki but also to any format.
Ludovic
Wang Ning wrote:
Hi Vincent & all,
I finish the clean of the plugin code and write a simple user manual. You
can see it in
http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter#HQuickStart. All
files needed for this plugin can be found in that page
http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter, except the
openoffice install .
Please give some feedback after try the plugin. Any feedback will be very
appreciated.
This plugin is very initial. It only put out the html code , not xwiki
syntax, because the html code to xwiki syntax conversion should be done by
XHTMLParser which is not ready yet.
Open question:
Now the plugin can handle the file which is uploaded to xwiki as a
attachment. Do you think it's necessary that the office importer would have
the upload feature itself or should provide a XWikiAction something like
"bin/importer/Main/page"?
Now the plugin can work. However it's a little complicate. If you want to
convert a office document
1. you first upload the document
2. copy the attachment name(because the name of document change after
upload)
3. edit the page and add the velocity code to use the importer plugin
4. save and view.
I think it should be more simple.
WDYT
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
5:41 p.m.
All I replies below are going to be consider in my next work.
On Mon, Jul 7, 2008 at 7:28 PM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
Hi,
I've tested the importer.. Installation and running it went fine !
Pretty cool. The documents where well imported in HTML with images
attached and converted.
Some bugs:
- a documents with accents was showing the accents in UTF-8 when my
wiki is ISO-8869-1. A conversion needs to be done.
I have no idea about the xwiki encoding system but I will learn it. I'll
keep this encoding problem in mind. Can you give me some detail suggestion?
Thanks very much.
Some remarks:
- it would be nice that the application can launch OO itself
I can do this:)
- you also need to write your code so that it can call the web service
version of jodconverter
You mean invoke a conversion service in a remote machine? I will create a
remote service converter class which implement the abstract converter to do
this. Use which converter can be configured in xwiki.cfg
- the application way would be nice to demonstrate and test the tool: a
file upload, you choose the page and the document is added at the end of
the page
I am planning to do in the application way:)
- one of the features of the conversion should be to convert any OO to
HTML or PDF and should be integrated as links next to attachment (view
as HTML or view as PDF).
The conversion between many formats is considered but I don't think I can do
it know. I will retain some useful interface for this feature. I will public
the interface to list for comment. WDYT?
Also there could be a macro to integrate the
HTML conversion in the middle of the page. Similar to {attach} but would
embed the document directly in the page. So you should make sure your
API allows to not only convert to wiki but also to any format.
Yes, this kind of api is my first thought and I implement it. The problem is
that, if I use the {import: test.doc} to insert the html code of conversion
to the page, the conversion method will be *invoked everytime* when the page
refresh. How to deal with this problem.
I have not develop a macro but I think I can do it. Can you give me some
sample?
Ludovic
Wang Ning wrote:
--
Sincerely,
Wang Ning
Hi Vincent & all,
I finish the clean of the plugin code and write a simple user manual. You
can see it in
http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter#HQuickStart.
All
files needed for this plugin can be found in that
page
http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter, except the
openoffice install .
Please give some feedback after try the plugin. Any feedback will be very
appreciated.
This plugin is very initial. It only put out the html code , not xwiki
syntax, because the html code to xwiki syntax conversion should be done
by
XHTMLParser which is not ready yet.
Open question:
Now the plugin can handle the file which is uploaded to xwiki as a
attachment. Do you think it's necessary that the office importer would
have
the upload feature itself or should provide a
XWikiAction something like
"bin/importer/Main/page"?
Now the plugin can work. However it's a little complicate. If you want to
convert a office document
1. you first upload the document
2. copy the attachment name(because the name of document change after
upload)
3. edit the page and add the velocity code to use the importer plugin
4. save and view.
I think it should be more simple.
WDYT
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:13 p.m.
Wang Ning wrote:
Yes and we would need this to pass firewalls which means being in HTTP
and with proxy settings..
I've commited some code that does it.. I think you should make the code
more modular and one calling the other..
Concerting to HTML is just a subset case of conversion.
Yes but we can include a cache of the conversion at the wiki level
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
All I replies below are going to be consider in my
next work.
On Mon, Jul 7, 2008 at 7:28 PM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
You should read $xwiki.encoding and make sure you convert to that
encoding anything that you put in wiki pages (that's not true for
attachments).
Hi,
I've tested the importer.. Installation and running it went fine !
Pretty cool. The documents where well imported in HTML with images
attached and converted.
Some bugs:
- a documents with accents was showing the accents in UTF-8 when my
wiki is ISO-8869-1. A conversion needs to be done.
I have no idea about the xwiki encoding system but I will learn it. I'll
keep this encoding problem in mind. Can you give me some detail suggestion?
Thanks very much.
Some remarks:
- it would be nice that the application can launch OO itself
I can do this:)
- you also need to write your code so that it
can call the web service
version of jodconverter
You mean invoke a conversion service in a remote machine? I will create a
remote service converter class which implement the abstract converter to do
this. Use which converter can be configured in xwiki.cfg
- the application way would be nice to
demonstrate and test the tool: a
file upload, you choose the page and the document is added at the end of
the page
I am planning to do in the application way:)
- one of the features of the conversion should
be to convert any OO to
HTML or PDF and should be integrated as links next to attachment (view
as HTML or view as PDF).
The conversion between many formats is considered but I don't think I can do
it know. I will retain some useful interface for this feature. I will public
the interface to list for comment. WDYT?
Also there
could be a macro to integrate the
HTML conversion in the middle of the page. Similar to {attach} but would
embed the document directly in the page. So you should make sure your
API allows to not only convert to wiki but also to any format.
Yes, this kind of api is my first thought and I implement it. The problem is
that, if I use the {import: test.doc} to insert the html code of conversion
to the page, the conversion method will be *invoked everytime* when the page
refresh. How to deal with this problem.
I have not develop a macro but I think I can do it. Can you give me some
sample?
Ludovic
Wang Ning wrote:
Hi Vincent & all,
I finish the clean of the plugin code and write a simple user manual. You
can see it in
http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter#HQuickStart.
All
files needed for this plugin can be found in that
page
http://dev.xwiki.org/xwiki/bin/view/Design/OfficeImporter, except the
openoffice install .
Please give some feedback after try the plugin. Any feedback will be very
appreciated.
This plugin is very initial. It only put out the html code , not xwiki
syntax, because the html code to xwiki syntax conversion should be done
by
XHTMLParser which is not ready yet.
Open question:
Now the plugin can handle the file which is uploaded to xwiki as a
attachment. Do you think it's necessary that the office importer would
have
the upload feature itself or should provide a
XWikiAction something like
"bin/importer/Main/page"?
Now the plugin can work. However it's a little complicate. If you want to
convert a office document
1. you first upload the document
2. copy the attachment name(because the name of document change after
upload)
3. edit the page and add the velocity code to use the importer plugin
4. save and view.
I think it should be more simple.
WDYT
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8 Jul
8 Jul
10:22 a.m.
Ludovic Dubost wrote:
Yes and we would need this to pass firewalls which means being in HTTP
and with proxy settings..
If you use standard JDK HTTP methods, then the proxy settings would be detected by the
JVM, or
configured at the JVM level, so there's no need for your code to handle the proxy
settings.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
- you also need to write your code so that it
can call the web service
version of jodconverter
You mean invoke a conversion service in a remote machine? I will create a
remote service converter class which implement the abstract converter to do
this. Use which converter can be configured in xwiki.cfg
10:25 a.m.
Wang Ning wrote:
You can look at com.xpn.xwiki.plugin.charts.ChartingMacro,
com.xpn.xwiki.plugin.graphviz.GraphVizMacro and
com.xpn.xwiki.plugin.svg.SVGMacro (they also contain caching code).
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Also there
could be a macro to integrate the
HTML conversion in the middle of the page. Similar to {attach} but would
embed the document directly in the page. So you should make sure your
API allows to not only convert to wiki but also to any format.
Yes, this kind of api is my first thought and I implement it. The problem is
that, if I use the {import: test.doc} to insert the html code of conversion
to the page, the conversion method will be *invoked everytime* when the page
refresh. How to deal with this problem.
I have not develop a macro but I think I can do it. Can you give me some
sample?
6011
days inactive
6012
days old
9 comments
4 participants
participants (4)
-
Guillaume Lerouge -
Ludovic Dubost -
Sergiu Dumitriu -
Wang Ning