On 3 août 08, at 21:40, malaka ekanayake wrote:
> Hi all,
>
> For the moment I would leave out the user defined macros and
> concentrate on the error reporting and $xwiki API assistance.
>
> WDYT?
>
> As you have told, I started looking at the $xwiki API and the ways
> to provide the content assistance.
>
> * But then I realized that it would be better off to provide content
> assistance to xwiki and velocity. XWiki content assistance is
> already implemented, I basically modified that implementation to
> provide content assistance to Velociry directives and variables.
>
Ok.
> * Earlier when the partition type was default_content there were
> only xwiki syntax. But Now we can expect both xwiki and velocity
> syntax. Now I need a way to provide completion proposals depending
> on whether it is xwiki or velocity. Therefore I implemented a
> DefaultCompletionProcessor which basicall delegates the computing of
> proposals to the appropriate completionProcessor depending on xwki
> or velocity. I didn' changed the functionaty of the exsisting
> XwikiCompletionProcessor.
>
I was looking at the XWikiCompletionProcessor and it has indeed to be
refactored because I think it's a bit messy.
There are some idiosyncrasies, for example structural completion and
link completion are done in this processor registered for the default
content type, while there are already a lot of partition type to
assign processors to (I will ask to Venkatesh for that).
> * Providing content assistance for Velociry directives is completed.
> The list of defined velocity variables can be extracted from the
> velocity parser. I could complete processing of proposals for
> variables using hardcoded list of variables. This can be replaced
> once I integrate the Velocity parser.
>
Ok.
> * When implementing above feature, i had to refactor the way, the
> document is partitioned. This also resulted in some changes in
> syntax colouring.
>
That's fine.
> Herewith I have attached the patch files, because I can't commit the
> code to sandbox. I've sent a mail regariding this to the mailing
> list before.
>
I've see that you were able to commit. I will review the code asap and
I'll get you feedback (I am abroad and the internet connection is not
very good).
> Now I am forcusing on provinding content assistance to the $xwiki
> API and integration of velocity parser.
>
Ok. Great.
Cheers,
Fabio
Hi Devs
I want to make a graph with a given table, but i don`t want to see the
table in the xwiki page, so i`m trying to make the graph inside my function:
Map data = new HashMap();
data.put("x", "1");
data.put("y", "110");
ChartingPlugin chartplugin = new
ChartingPlugin("chartingplugin", ChartingPlugin.class.toString(), context);
chartplugin.init(context);
// ChartingPluginApi chart = new
ChartingPluginApi(chartplugin,context);
ChartParams chartParams = new ChartParams();
try {
chartParams = new ChartParams(data,
DefaultChartParams.getInstance(), true);
chartParams.addParam(new
MapChartParam("source=type:table", false));
chartParams.addParam(new
MapChartParam("type=pie", false));
// chartParams.set("SOURCE", "type:table");
// chartParams.set("TYPE", "pie");
chartParams.check();
} catch (ParamException e) {
}
* Chart chart = new ChartImpl(chartParams,null,null);
try {
chart = chartplugin.generateChart(chartParams,
context);
} catch (GenerateException ge) {
}*
String title = chartParams.getString(
ChartParams.TITLE_PREFIX+ChartParams.TITLE_SUFFIX);
Integer height = chartParams.getInteger(ChartParams.HEIGHT);
Integer width = chartParams.getInteger(ChartParams.WIDTH);
Map imageAttr =
chartParams.getMap(ChartParams.IMAGE_ATTRIBUTES);
Map linkAttr =
chartParams.getMap(ChartParams.LINK_ATTRIBUTES);
// output the image links
StringBuffer sbuffer = new StringBuffer();
sbuffer.append("<a href=\""+ chart.getPageURL() + "\" ");
if (title != null) {
sbuffer.append("title=\"" + title + "\"");
}
if (linkAttr != null) {
Iterator it = linkAttr.keySet().iterator();
while (it.hasNext()) {
String name = (String)it.next();
String value = (String)imageAttr.get(name);
sbuffer.append(name+"=\"" + value + "\" ");
}
}
sbuffer.append(">");
sbuffer.append("<img src=\"");
sbuffer.append(chart.getImageURL());
sbuffer.append("\" ");
if (title != null) {
sbuffer.append("alt=\""+ title + "\" ");
}
sbuffer.append("height=\"" + height + "\" ");
sbuffer.append("width=\"" + width + "\" ");
if (imageAttr != null) {
Iterator it = imageAttr.keySet().iterator();
while (it.hasNext()) {
String name = (String)it.next();
if (name != ChartParams.HEIGHT && name !=
ChartParams.WIDTH) {
String value = (String)imageAttr.get(name);
sbuffer.append(name + "=\"" + value + "\" ");
} else {
}
}
}
sbuffer.append("/>");
sbuffer.append("</a>");
return sbuffer.toString();
I get some problems in :
* Chart chart = new ChartImpl(chartParams,null,null);
try {
chart = chartplugin.generateChart(chartParams,
context);
} catch (GenerateException ge) {
}
*I think is some problem with the source,
Any ideas?
Thanks in advance :)
Hi all
I have a question when I insert a table each table recives an ID the can be
used to define wich table to use to creat a Chart.
My question is How can I obtain this id. for Example I want to do the
following
This is Table ID = ? (0)
{table}
A | B
1 | 2
{table}
This is Table ID = ? (1)
{table}
E | D
1 | 2
{table}
And if I delete table 0:
This is Table ID = ? (0)
{table}
E | D
1 | 2
{table}
Hope Someone can help me thanks.
--
View this message in context: http://n2.nabble.com/Tables-Id-tp668637p668637.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
As per the previous thread on the topic (see http://is.gd/1bRm ), Proposal
n°4 attracted the most positive feedback for the WYSIWYG GUI (you can see it
here : http://is.gd/1bRo ) . If nobody has anything against it, I'd like to
get things forward and ask a real designer (that is, other than me :-) ) to
review it and propose a good-looking version of the proposal. Therefore
please shout now or never if you're against it !
Additionnaly, if you look into the proposal you'll see that we will need to
decide between 2 options for advanced input interaction : a modal dialog box
versus a tray. Both have advantages and issues and I'd like to get feedback
about them. The dialog box prevents interaction with background content
while the tray allows it : that could be useful for tables for instance.
Looking forward your feedback,
Guillaume
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://blog.xwiki.com/
Hi all,
I got the following error when trying to commit the code to the sandbox.
svn: Commit failed (details follow):
svn: MKACTIVITY of
'/svnroot/xwiki/!svn/act/fbb5e27f-9dbe-4b48-9ac2-8bee460b2e86':
authorization failed (https://svn.xwiki.org)
I could commit code before the restructuring of the svn repository.
Can you help me on this?
--
Malaka Ekanayake
CSE UOM
dear all,
I am samir CHAKOUR developer for a partner of XWiki and I'm
currently working on a Calendar for the XWiki Platform,
the project is to developed in
GWT and is working with XWiki-GWT API, the project is located at https://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-calendar,
currently the project is only in its first brick, and will be usable by the end of August,
best regards,
Samir CHAKOUR
_________________________________________________________________
Votre correspondant a choisi Hotmail, un e-mail ultra sécurisé. Créez le votre gratuitement !
http://www.windowslive.fr/hotmail/default.asp
Hi,
When converting a ppt or odp document, the result of the conversion
is some html files contain text and html files contain jpg images. A
text html and a image html snapshot for per slide. And have the
navigation links in per html, some thing like "First page" "Back"
"Continue" "Last page" "Text"/"graph".
For instance, the ppt with 3 slides will turn out:
text1.html
text2.html
text3.html
img1.html
img2.html
img3.html
img1.jpg
img2.jpg
img3.jpg
The img1.html is just the html file contain the img1.jpg.
The return of the conversion only is the first page html, img1.html,
which is not enough for the conversion result.
The text1.html is the text version of the slide which doesn't contain
any images in the source document.
The img1.html is the snapshot of the original ppt slide which can
display everything in the source document.
There are three way to handle the ppt conversion.
1. assemble the text version of slide "text1.html, text2.html ..." to
a final result. gmail's "view as html" of the attachment go this way.
But this can lose the images of original document.
2. compress all the output file to a zip file and attach the zip file
to the xwiki page. Then view the zip file content, like
http://code.xwiki.org/xwiki/bin/view/Snippets/ViewOfficeDocumentSnippet
does.
3. assemble the image version of slide to a final result.
BTW, I'm working on the "view as html" of office document in xwiki
page attachment. I have two way to display the result html.
1. display the result html in a pure normal html page. This way is
hard to display the image. Maybe "view as html" can ignore the image
of the documents, as the office import feature can handle the image
well.
2. put the result html page in a xwiki page content and display the
xwiki page. This way can address the image as page attachment easily.
WDYT?
Please help me to make those two decisions.
Thanks.
Wang Ning
I've done some larger testing with a wiki with 4000 documents. The
integration worked well (except some plexus init change needed).
However the system is quite slow when getting to big directories.
Although we can improve the server part, I think it's a bad idea to have
by design large directories. Operating System WebDAV client can be very
aggressive (downloading files to generate thumbnails, making requests
looking for temporary files). I was able to improve the speed of error
handling however there are still way too many calls to the server.
For example the attachment view has more than 1000 documents. This makes
more than 2000 request to display with the MAC OSX WebDAV client.
So I propose to change our view to make it almost impossible to get to
large directories in our WebDAV view. The general principle is to
breakdown by space name and then breakdown by the first letters for the
page name.
For example the attachment view instead of being
attachments/pagename/attachmentname
would beconde
attachments/spacename/firstletters/pagename/attachmentname
firstletters would be the first letters of pages existing in that view.
It could be one letter, two letters, three letters or could change based
on the number of pages in the view.
For example it could be one letter with less than 200 documents, two
with less 5000, three more than 5000.
We could go up to 100000 documents with folders of around 30 pages with
a 3 letter subdirectory.
I've detailed the view proposal here:
http://dev.xwiki.org/xwiki/bin/view/Design/WebDAVService
WDYT ?
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost