Hi devs,
Following the previous mail with the desired improvements for the annotation
feature, I would like to discuss some options for implementing the first of the
enhancements, namely the ability to configure easily the type of added
annotation. (see
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HFeaturesimpro…
for details).
Two alternatives for this would be:
A) to preserve the current architecture of the annotations plugin and only add a
map of "extra fields" to the annotation type. The type of the annotation would
be known by the js client through the configuration of an XWiki class and the js
client would create a "generic" form for any such type.
See more details about this solution at
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution1extr…
.
Pros: preserves the current annotations architecture, creates an easy way to
plug an annotation storage service
Cons: the Annotation class would be nothing else but a "BaseCollection" the same
as a generic XWiki object, and we would be reimplementing view, save, edit,
delete of this type (already implemented through the xwiki action) from the web
forms level (editing and displaying an annotation), through the controller (REST
this time instead of actions in the standard wiki servlet), to the storage level
(XWikiIOService will only transform a map (the Annotation class) to another map
(the XWikiObject in the xwiki document)).
B) to make an XWiki object model based implementation where the js client, to
create the UI, would just asynchronously fetch standard actions in XWiki (edit,
view, save). In this case, where all is handled exclusively through the XWiki
model, Scribo would be plugged as an external service performing periodic
updates between the XWiki instance and its RDF store.
See more details about this solution at:
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution2XWik…
Pros: uses the xwiki object model 100%, there's no reimplementing of the whole
process of saving, editing objects, etc, the forms and views are light
customizations of standard XWiki mechanisms
Cons: the annotation mapping to document source cannot be implemented
straightforward (there are changes needed in the architecture and algorithm),
Scribo (or any other storage model different from XWiki) would need to duplicate
data, and it would not be 100% real time (since it would be a periodical
synchronizer)
The current implementation is illustrated in the
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HCurrentImplem…
section.
I like the elegance of the first solution more, for the way a different storage
can be easily plugged, but I don't like that we're reimplementing a lot of XWiki
objects manipulation (which is why 2 would be a better solution).
WDYT?
Thanks,
Anca
Hi Marius,
I tried the the first way, "i) access the editor in Java (GWT) code by
writing a simple native getter", the dependency is killing me. I can not
compile it use eclipse the dependency is the way too complicated. I tried
use maven to build it, but I tried for a whole afternoon and I really don't
know how to write the correct pom to compile them together.
Could you please extend the native JavaScript API so that I can write
something like:
native void setBackgroudColor(String color)
/*-{
editorJSReference.execute('backcolor', color);
}-*/;
Could you please also tell me what you did to extend the native JavaScript
API, so I can learn about how to save the location of highlighted sentence
to help software maintainer easily trace back to the high lighted document.
If you want I can collect your reply and write document for you for this
one too.
Here is another problem, please see the screenshot:
http://picasaweb.google.com/freeleons/Xwiki#5394862411574232850 in the
WYSIWYG edit mode, the customized sidebar are disappeared, which means that
I can not use the GWT tree to interact with the WYSIWYG editor. Is there
anyway to keep the customized toolbar?
I have finished the document writeup here is the url:
http://dev.xwiki.org/xwiki/bin/view/Drafts/LoadingGWTApplicationsInXWik
You are literally saving my life. Thank you so much!
I've done a nice experiment with SocialCalc and I'm pretty happy of the
results:
It allows to edit a spreadsheet stored in a Wiki Page. It lacks a
server-side transformation of the spreadsheet to a Wiki table for
rendering, printing and pdfs, but it's already interesting.
http://incubator.myxwiki.org/xwiki/bin/view/Test/Calc
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hello Devs,
As I understand, If a wiki macro supports inline mode and is executed as an
inline macro, it must be true that the output generated by the macro does
not contain block elements (otherwise the result will not be inline). From
the wiki macro bridge code we have the following check:
<code>
List<Block> result = xdom.getChildren();
// If in inline mode remove any top level paragraph.
if (context.isInline()) {
this.parserUtils.removeTopLevelParagraph(result);
}
</code>
This only removes the top-level paragraph block. It's possible that inside
the content there are more block level elements, I think this is where we
need the inline parser.
Another problem i discovered is if i have a wiki macro with macro code:
<code>
{{velocity}}
.....
{{/velocity}}
</code>
This makes the {{velocity}} macro behave in a non-inline fashion regardless
of the wiki macro's intentions. Further more, the paragraph block generated
by the {{velocity}} macro is not stripped by the check I mentioned above.
This is because the paragraph block resides inside a MacroMarkerBlock (so it
is not a top-level paragraph).
A workaround I found for this problem is to have something like:
<code>
{{html}}{{/html}}{{velocity}}
.....
{{/velocity}}
</code>
This is only a hack to force the {{velocity}} macro ro behave in an inline
fashion.
Now I'm wondering if we should wait for the inline parser to be available to
fix this or do some custom hacking to get rid of the block elements
generated while executing in inline mode. wdyt?
Thanks.
- Asiri
Hi,
The XWiki project is now fully set up on Nemo here:
http://nemo.sonarsource.org/components/index/XWIKI
Comments:
* Since our junit test no longer fail with memory issue they've added
back test coverage stats. Link to platform: http://nemo.sonarsource.org/project/index/178319
* They've just added the "Commented LOC" stat feature which shows the
number of lines of commented code. We shouldn't have any commented out
code so we'll need to gradually reduce this too.
* The test coverage don't count integration and functional tests, i.e.
if a unit tests tests code from another module the coverage is not
taken into account. Thus all our rendering tests in xwiki-rendering-
tests are not taken into account (they cover 90% of the rendering api
code...).
* Since they've added the unit tests the tech debt has gone down a
lot. I'll ask them why.
Thanks
-Vincent