Hi devs,
Currently in xwiki syntax 2.0 we are using
|| title cell 1 || title cell2
| cell 1 | cell 2
for table syntax.
The problem is that with this grammar it's impossible to have empty
cells because you can't use || as it mean title cell.
Creole is using (see
http://www.wikicreole.org/wiki/Creole1.0#section-Creole1.0-Tables):
|= title cell 1 |= title cell2 |
| cell 1 | cell 2 |
I propose to change our current || by |= meaning the difference with
the Creole syntax will be just that we don't need the ending |:
|= title cell 1 |= title cell2
| cell 1 | cell 2
- we generally agreed to use Creole as much as possible
- this syntax support space
- this cell header syntax is more consistent with our header syntax
(which is the Creole one ok ;))
- I think it's more readable than the current one because it's easier
to differentiate header cell and cell especially when there is lot's
of them
So here is my +1
--
Thomas Mortagne
Hello devs,
This week we created a new "xwiki-macros" module under platform/core/
for macros of the XWiki Syntax 2.0. Another question now is what do we
do for macros that are not "core macros" (i.e. not indispensable for
what we consider being the basic working wiki, unlike the TOC macro, or
the velocity macro). Development of such macros already started, for
example the instant messenger status macro, and the map macro.
Possibilities I see :
1. having them at the same level we have applications/ plugins/ under
platform : adding a macros/ directory.
2. having them in the xwiki-macros core submodule, despite the fact they
are not core
I am for solution 1 right now, but maybe there are better alternatives
to this, too.
We also have to decide how we do release and distribute them, for
example do we pack them with XE, or do we release them separately, and
let users install them themselves as it is the case for most of the
applications already. (For me the answer to this latest question seems
obvious : we _should_ send them together with XE)
Let me know what you think, I'd like if still possible having the map
macro in 1.7 RC1.
Jerome.
Hi Asiri,
On Nov 24, 2008, at 6:08 PM, asiri (SVN) wrote:
> Author: asiri
> Date: 2008-11-24 18:08:51 +0100 (Mon, 24 Nov 2008)
> New Revision: 14425
>
> Modified:
> sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/
> plugin/officeimporter/filter/RedundantTagFilter.java
> Log:
> XAOFFICE-1 : Develop the initial feature set for office-importer
> plugin.
>
> * Added support for filtering empty / redundant paragraphs.
>
> Modified: sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/
> xwiki/plugin/officeimporter/filter/RedundantTagFilter.java
> ===================================================================
> --- sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/
> plugin/officeimporter/filter/RedundantTagFilter.java 2008-11-24
> 15:17:17 UTC (rev 14424)
> +++ sandbox/xwiki-plugin-officeimporter/src/main/java/com/xpn/xwiki/
> plugin/officeimporter/filter/RedundantTagFilter.java 2008-11-24
> 17:08:51 UTC (rev 14425)
> @@ -31,12 +31,13 @@
>
> public void filter(Document document, ImporterContext context)
> {
> - for(String key : attributeWiseFilteredTags) {
> + for (String key : attributeWiseFilteredTags) {
>
> filterNodesWithZeroAttributes(document.getElementsByTagName(key));
> }
> - for(String key : contentWiseFilteredTags) {
> + for (String key : contentWiseFilteredTags) {
>
> filterNodesWithEmptyTextContent(document.getElementsByTagName(key));
> - }
> + }
> + filterEmptyParagraphs(document);
> }
>
> /**
> @@ -70,10 +71,35 @@
> {
> for (int i = 0; i < elements.getLength(); i++) {
> Element element = (Element) elements.item(i);
> - if (element.getTextContent().trim().equals("")) {
> + if (element.getTextContent().trim().equals("")) {
> element.getParentNode().removeChild(element);
> i--;
> }
> }
> }
> +
> + /**
> + * OpenOffice server generates redundant paragraphs (with empty
> content) to achieve spacing.
> + * These paragraphs should be stripped off / replaced with
> {@code <br/>} elements appropriately
> + * because otherwise they result in spurious {@code (%%)}
> elements in generated xwiki content.
> + *
> + * @param document The html document.
> + */
> + private void filterEmptyParagraphs(Document document)
> + {
> + NodeList paragraphs = document.getElementsByTagName("p");
> + for (int i = 0; i < paragraphs.getLength(); i++) {
> + Element paragraph = (Element) paragraphs.item(i);
> + if (paragraph.getTextContent().trim().equals("")) {
> + // We suspect this is an empty paragraph but it is
> possible that it contains other
> + // non-textual tags like images. For the moment
> we'll only search for internal image
> + // tags, we might have to refine this criterion
> later.
> + NodeList internalImages =
> paragraph.getElementsByTagName("img");
> + if (internalImages.getLength() == 0) {
> + paragraph.getParentNode().removeChild(paragraph);
> + i--;
I don't understand this algorithm. There can be a lot of other valid
XHTML elements inside a P element (see the XHTML spec). Why are you
searching for IMG tags at all? What about all the other tags?
Again I'm not sure this code is in the right place. For example what
will happen if the user provides an empty P as input for a wiki page
(using XHTML syntax)? Your code will never run in this case.
To be honest I haven't looked at the office importer code for some
time but we really need to be careful to move all generic code outside
of it and into the HTML cleaner or into the XHTML parser. Could you
please check that there are only office-related code in there?
Thanks
-Vincent
Hi,
I'm attempting to develop a couple of plugins to integrate XWiki into
a portal solution.
Unfortunately I'm having problems getting a debug session going in
Eclipse. I followed
the instructions in the XWiki dev wiki to the letter, with the small
change of going from
1.6 (as stated in the wiki examples) to 1.7, which seems to be the
latest snapshot. Also
I'm using Tomcat 6.
I get the following exception when attempting to run the app on the
server:
SEVERE: Error configuring application listener of class
org.xwiki.container.servlet.XWikiPlexusServletContextListener
java.lang.ClassNotFoundException:
org.xwiki.container.servlet.XWikiPlexusServletContextListener
at
org
.apache
.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:
1360)
at
org
.apache
.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:
1206)
at
org
.apache
.catalina.core.StandardContext.listenerStart(StandardContext.java:3786)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:
4350)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:
1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:
1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:
443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:
710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
I also noticed that the tmp0/wtpapps/xe-debug-web/WEB-INF/lib
directory only contains the plugin code.
All other dependencies are not pulled in. That does not seem right.
I'm using Eclipse 3.4, M2Eclipse 0.9.6 and Tomcat 6.
Here is the xe-debug-web's pom file:
Hi devs!
As you know XWQL was introduced in 1.6, but without some easy access
from scripts. Currently it is accessible via
$xwiki.xWiki.store.queryManager.createQuery(stmt, "xwql") and only with
programming rights.
We need some easy ways to access to XWQL similar as
$xwiki.searchDocuments, countDocuments and search. This will allow to
users much more test XWQL and send us feedback.
I planed to implement this by 1.7RC1 or 1.7. This is just an interface
for xwiki scripts and doesn't affect to important parts of platform.
Name of this service?
1. $xwiki.queryManager ($xwiki.query is occupied by old QueryPlugin)
Later this will be obsoleted by 2.
or
2. $services.query
$services was proposed in our velocity bridge proposal[1]. We may
implement only $service now as just simple services holder, without
uberspectors.
$services will be reimplemented later, but "$service.query" name will
be saved.
[1] http://markmail.org/message/nnybto3mluvp2rov
I'm for 1 because velocity bridge isn't exist yet and its design may be
changed.
Technically it will be just some proxy for QueryManager and Query with
access right checking.
Functionality?
1. Just the same as QueryManager
so: .createQuery("stmt", "lang").execute()
or
2. The same as QueryManager + .xwql("stmt") method which will call
.createQuery("stmt", "xwql")
.xwql("stmt") is much more laconically than createQuery. Later it may
be transparently replaced by 3.
or
3. QueryManager + dynamic methods like .language("stmt")
impossible without velocity bridge uberspectors.
I'm for 2.
Access rights?
One way:
1. short-form xwql queries like
"where <whereexpr>" and "from <fromexp> where <whereexpr>"
return only document names, so
will be available for everyone.
this is analogue for $xwiki.searchDocuments()
2. full-form xwql ("select <selectlist> from <etc>" )
will require programming rights.
this is analogue for $xwiki.search()
3. all other languages (currently only HQL) in QueryManager will require
programming rights.
4. Query.setWiki will require programming rights.
So we need to wrap Query with some SecureQuery.
How should be analogue for "$xwiki.countDocuments"?
Ways:
0. No analogue. just query.execute().size()
JCRSQL2 has no aggregate functions at all.
We could make lazy query result list to fix negatives.
1. just accept all queries like "select count(*) ..."
("*" is not supported in count() according jpql)
2. implement some simple syntax extension in xwql:
"count [from ...] where ..."
no parser change, just replace the statement prefix
I'm 0 for now.
WDYT?
--
Artem Melentyev
Hi,
I'd like to propose this design
<http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature> for
annotation feature implementation.
Vote is about choosing between solution 1 and 2.
if we can have an (almost) perfect bijective function between HTML and
XWiki code, I'm +1 for solution 2 because implementation will be more
efficient , stable and clean.
Otherwise solution 1 seems to be a good solution.
WDYT?
Lucien
Six +1, no 0, no -1. Vote passed.
Thanks,
JV.
On Fri, Nov 21, 2008 at 10:33 AM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
> Hi XWikiers,
>
> I've started to refactor WYSIWYG mockups according to the last
> discussions on the list. For this first vote I propose to validate its
> general layout.
> The mockup can be found here, I hope it is self-explaining :
> http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HToolb…
> You can ignore the inline syntax help in wiki mode, it was just a
> thought while doing the mockup.
>
> Here's my +1.
>
> JV.
>