Hi all,
I am working with a XE 1.3.8295 installation where RTF export works
fine. But it will be great programmatically control the output layout
(namely, pictures printed size, space before and after paragraphs or
headings, space before and after pictures, footnotes,...
Please, could you point me in the right direction to face this requirement?
Thanks indeed for your help.
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
Hi Vincent,
I read this in htmlcleaner's forum,
http://sourceforge.net/forum/forum.php?thread_id=1935192&forum_id=637245.
It seams that htmlcleaner can't handle the deprecated tags. So I think
I can't use htmlcleaner to to transform deprecated tags in the "html
clean" step, unless I use jdom.
PS. I don't think jdom is a so bad way for now.
Thanks
Wang Ning
Hi,
I'd like to create a new core module called xwiki-xml which contains
xwiki utility classes to help parse XML.
The first need I have is to put inside an Entity resolver so that DTDs
can be resolved locally.
The idea is to move the following files currently located in xwiki-core:
* XWikiURIResolver
* xhtml1-*.dtd (2 files)
* xhtml-*.ent (3 files)
I need this in the new rendering XHTML macro to support entities.
In the future we could put there any generic code useful for handling
XML (and for which we don't have any external framework to use of
course).
Here's my +1
Thanks
-Vincent
Hi Vincent,
I run a test case for <del> and it does not work.
In XDOMGeneratorListener#endFormat(WikiFormat format) you use
(format.hasStyle(IWemConstants.STRIKE)) to handle the strickout, but
both <s> and <strike> are deprecated in xhtml. Why not use
(format.hasStyle(IWemConstants.DEL))?
WDYT?
Thanks
Wang Ning
Hi,
I've reviewed SyndEntryDocumentSourceTest and I've found some
problems:
1) In testSourceAccessRights()
253 1 try {
254 1 source.source(new SyndEntryImpl(), doc,
Collections.EMPTY_MAP, getContext());
255 0 assertTrue(ACCESS_RIGHTS_VIOLATED, false);
256 } catch (XWikiException e) {
257 // we should get an exception
258 }
This is not the correct way:
* the assertTrue is never executed since the test expects an exception
to be thrown
* instead the assertTrue should be replaced by a fail("Should have
thrown an exception here")
* the catch should have an exception name of "expected" instead of "e"
to signify that this is expected
* the exception should be checked in the catch to verify it's the
correct one we get
259 // even user name length implies all access rights
260 1 getContext().setUser("Condor");
261 1 try {
262 1 source.source(new SyndEntryImpl(), doc,
Collections.EMPTY_MAP, getContext());
263 // we shouldn't get an exception
264 } catch (XWikiException e) {
265 0 assertTrue(ACCESS_RIGHTS_VIOLATED, false);
266 }
Same here
2) In initArticleClass()
167 7 XWikiDocument doc;
168 7 boolean needsUpdate = false;
169
170 7 try {
171 7 doc = getContext().getWiki().getDocument(ARTICLE_CLASS_NAME,
getContext());
172 } catch (Exception e) {
173 0 doc = new XWikiDocument();
174 0 doc.setFullName(ARTICLE_CLASS_NAME);
175 0 needsUpdate = true;
176 }
177
178 7 BaseClass bclass = doc.getxWikiClass();
179 7 bclass.setName(ARTICLE_CLASS_NAME);
180
181 7 needsUpdate |= bclass.addTextField("title", "Title", 64);
182 7 needsUpdate |= bclass.addTextAreaField("content", "Content",
45, 4);
183 7 needsUpdate |= bclass.addTextField("category", "Category", 64);
184
185 7 String content = doc.getContent();
186 7 if ((content == null) || (content.equals(""))) {
187 0 needsUpdate = true;
188 0 doc.setContent("1 XWiki.ArticleClass");
189 }
190
191 7 if (needsUpdate) {
192 7 getContext().getWiki().saveDocument(doc, getContext());
193 }
194 7 return bclass;
195 }
* Lines 173-175 are never called.
* Lines 187-188 are never called too.
Could the writer of this test please fix this?
Thanks
-Vincent
Hi,
There are some pb with PeriodFactoryTest. For example:
public void testDayPeriodStartEndCode()...
40 {
41 1 Period day =
PeriodFactory.createDayPeriod(System.currentTimeMillis());
42 1 SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd");
43 1 try {
44 1 long start =
sdf.parse(String.valueOf(day.getStartCode())).getTime();
45 1 long end =
sdf.parse(String.valueOf(day.getEndCode())).getTime();
46 1 assertTrue("Start code must be less than end code", start <
end);
47 } catch (ParseException e) {
48 0 assertTrue(e.getMessage(), false);
49 }
50 }
51
This test isn't expecting an exception to be raised and thus it should:
* throw an Exception in its signature
* remove the try/catch block
The other test methods should also be fixed similarly.
Could the writer of this test please fix this?
Thanks
-Vincent
Hi devs,
I'm trying to integrate the new WYSIWYG editor into XWiki's page editing
mechanism and I'm having an issue regarding how the edited content is
being submitted.
Right now (correct me if I'm wrong) when the user clicks "Save & View" the
edit form is submitted having a "content" field filled with the result of
converting editor's HTML output to XWiki syntax. Two things should be
noted:
* the conversion takes place on the client side, in JavaScript code;
* the save action, on the server side, expects XWiki code, not (X)HTML.
In the case of the new WYSIWYG editor, converting the (X)HTML to XWiki on
the client side is out of discussion. I must use the new rendering module,
which is written in Java. In order to smoothly integrate the new editor I
have to make sure the save action gets the XWiki code it expects.
Asynchronously retrieving the result of the conversion before submitting
the edit form is tricky due to the fact that the user can click "Save &
View" before the response arrives.
In light of this, Sergiu suggested me the following 2 solutions:
A) Retrieve the conversion synchronously
This would be easy if GWT would allow it. Instead I'd have to write
error-prone code using timeout to wait for the response and then release
the form submit.
B) Use a servlet filter
I'd have to write a servlet filter that detects the save action,
determines the editor (wysiwyg, new_wysiwyg, wiki etc.) and the syntax of
the submitted content (XWiki by default, XHTML for the new editor) and
makes the conversion, if needed.
I prefer the second solution. WDYT?
Regards,
Marius