Forwarded to get past the list.
Begin forwarded message:
> From: Guillaume Lerouge <me(a)guillaumelerouge.com>
> Date: 16 août 2009 13:22:49 HAEC
> To: XWiki Developers <devs(a)xwiki.org>
> Subject: Re: [xwiki-devs] [Proposal] XWiki 2.0 Skin
>
> Hi Thibaut,
>
> Thanks a lot for your feedback!
>
> About the tabbed mockups: thanks for the personas, they're useful
> and we should use the concept more when working on our designs.
>
> Jean-Vincent had concerns similar to yours about tabs and we
> explored another option that made more use of buttons located close
> to the content area last Friday. We will definitely keep exploring
> options for a new skin / UX in the coming months and we'll be
> looking for your feedback during that time.
>
> On 16 août 2009, at 12:48, ThibautDeveraux <thibaut.deveraux(a)gmail.c
> om> wrote:
>
>>
>> Sorry 3 mail...
>>
>> I missed the last post. about this skin :
>>
>> http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposa…
>>
>> Well, it is obviously the same architecture as currently. I
>> understand that
>> there is not much time.
>
> We've got only 2 weeks to change XWiki's look before 2.0 and we
> won't realistically be able to do much more than freshen it up a bit
> and make the logo easier to change.
>
>
>>
>> I hope it is not definitve. I'd really prefer a skin with page
>> related
>> actions located near page.
>>
> We'll keep working on it during our next releases I promise :-)
>
>
>>
>> Also I'd love to make propositions of architecture modifications to
>> visauy
>> show my means. Yet I have not many time. Is there a place where
>> source files
>> can be downloaded to speed the process ?
>>
> I'll let Caty / JV answer about this.
>
> Thanks for your help,
>
> Guillaume
>
>
>> Have a nice day
>>
>> Thibaut
>> --
>> View this message in context: http://n2.nabble.com/-Proposal--XWiki-2.0-Skin-tp3405623p3453159.html
>> Sent from the XWiki- Dev mailing list archive at Nabble.com.
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
Hi,
Some date change proposal since we're late on a few things:
* RC1: move it to 24th of Aug (instead of 17th). It must contain:
- bug fixes - All
- distributed events done - Thomas
- WYSIWYG changes for macro category - Marius
- new skin: background + full horizontal width header + some CSS
colors - Cati
- watchlist working for XEM - JV
* 2.0 final: 31st of Aug (unless we find critical bugs in RC1 in which
case we'll do a RC2 and postpone the final to the 7th of Sep.)
Here's my +1
Thanks
-Vincent
Hi,
I find it really not easy to use a sortable/filterable table in xwiki
now + it exposes internals (like name and location of CSS and JS
scripts):
Syntax 1.0:
$xwiki.ssfx.use("js/xwiki/table/table.css")
$xwiki.jsfx.use("js/xwiki/table/tablefilterNsort.js", true)
<table id="tableid" class="grid sortable filterable doOddEven">
..
</table>
Syntax 2.0:
{{velocity}}
$xwiki.ssfx.use("js/xwiki/table/table.css")
$xwiki.jsfx.use("js/xwiki/table/tablefilterNsort.js", true)
{{/velocity}}
{{html}}
<table id="tableid" class="grid sortable filterable doOddEven">
..
</table>
{{/html}}
What's the best practice? How do we fix this quickly? (the longer fix
is to implement either sorting/fitering at the syntax level using
parameters or by introducing a new generic table/grid macro).
Do we remove the documentation for this? (it's currently on the syntax
page and broken since it doesn' t mention using ssfx/jsfx).
Thanks
-Vincent
Hi,
Input:
(% style="color:blue" %)
= header =
The result doesn't show the header in blue. The reason is that we have
the following CSS in toucan:
h1 span, h2 span, h3 span, h4 span {
background-color:inherit;
border-bottom:1px solid #CCCCCC;
color:#000000;
display:block;
margin:20px 0;
overflow:hidden;
padding:0;
position:relative;
}
It doesn't work since the style is set on h1 and the span's style is
overidden in toucan's css.
Question: Why don't we set the styles above on h1 instead of h1 span
for ex?
What can we do to fix this?
I don't think that changing the XHTML renderer to set the style on the
span would be a good thing. WDYT?
Thanks
-Vincent
Hi,
Concerning DocumentAccessBridge [0], would it be possible to add
another setProperty method, which would indicate
the number(index) of the object you add the property value to? Its
signature would be:
void setProperty(String documentName, String className, int
objectNumber, String propertyName, Object propertyValue) throws
Exception;
I need it to be able to easily add new objects and modify their
property values, from a component.
Is there any other way of doing this I overlooked?
Right now, the only existing setProperty method operates only on the
first object attached to the document:
void setProperty(String documentName, String className, String
propertyName, Object propertyValue) throws Exception;
The corresponding getters are both already present:
Object getProperty(String documentName, String className, int
objectNumber, String propertyName);
Object getProperty(String documentName, String className, String propertyName);
WDYT?
[0] - https://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-bridge/src/ma…
Thanks,
Anamaria
Hi everybody!
Sorry for bother you again with my questions, but I have a problem that
blocks me. I need to know what images are internal (they are attached to
the current page or other XWiki page) in order to download them with my
XMLRPC client. Using the rendering module I get every ImageBlock [1] and I
check the ImageType[2] of every Image[3] object. My problem is that this
type is URL for both external and internal images and that's why I can't
cast to the DocumentImage class. I've pasted bellow my code and the output
for some inputs. Can somebody tell me what I am wrong? Is there any other
solution for getting the associated attachments?
My client has these methods for getting the attachment data:
- Attachment<http://confluence.atlassian.com/display/DOC/Remote+API+Specification#Remote…>
getAttachment(String
token, String pageId, String fileName, String versionNumber) - get
information about an attachment.
- byte[] getAttachmentData(String token, String pageId, String fileName,
String versionNumber) - get the contents of an attachment.
- byte[] getAttachmentData(Attachment attachment) - get the contents of
an attachment.
My code:
// Parse
Parser parser = ecm.lookup(Parser.class, syntax.toIdString());
XDOM xdom = parser.parse(new StringReader(source));
for (ImageBlock block : xdom.getChildrenByType(ImageBlock.class,
true)) {
Image image = block.getImage();
System.out.println(image.getType() + "");
System.out.println(image.getName() + "");
}
Tests:
Input:
source: [[image:IMG3219.JPG]]
image:http://www.balsamiq.com/images/xwiki_logo.png
Syntax : XWIKI_2_0
Output:
URL
IMG3219.JPG
URL
http://www.balsamiq.com/images/xwiki_logo.png
Input:
source: <p><img src="IMG3219.JPG" alt="IMG3219.JPG"/><br/><br/><img src="
http://www.balsamiq.com/images/xwiki_logo.png"
class="wikimodel-freestanding" alt="
http://www.balsamiq.com/images/xwiki_logo.png"/></p>
syntax: XHTML_1_0
Output:
URL
IMG3219.JPG
URL
http://www.balsamiq.com/images/xwiki_logo.png
Links:
[1]
http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rendering/xwik…
[2]
http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rendering/xwik…
[3]
http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rendering/xwik…
Best regards,
Cristina
Hi,
I'd like to move syntax-related classes to org.rendering.syntax
package. These are:
- Syntax
- SyntaxFactory
- SyntaxType
Right now they are in the org.rendering.parser package but that's not
right since Syntax classes are used in Listeners, Parsers,
Transformations, etc which are all top level rendering packages.
This will break the API and is not backward compatible (for those
using the rendering api directly) which is why I'd like to do this
ASAP so that it's in XE 2.0 (which doesn't have to be backward
compatible).
Note that we already have lots of api breakage for the rendering module:
<exclude>org/xwiki/rendering/listener/chaining/
AbstractChainingListener</exclude>
<exclude>org/xwiki/rendering/renderer/EventsRenderer</
exclude>
<exclude>org/xwiki/rendering/renderer/
PlainTextRenderer</exclude>
<exclude>org/xwiki/rendering/renderer/TexRenderer</
exclude>
<exclude>org/xwiki/rendering/renderer/XHTMLRenderer</
exclude>
<exclude>org/xwiki/rendering/renderer/
XWikiSyntaxRenderer</exclude>
<exclude>org/xwiki/rendering/renderer/
PrintRendererFactory</exclude>
<exclude>org/xwiki/rendering/renderer/PrintRenderer</
exclude>
<exclude>org/xwiki/rendering/renderer/chaining/
AbstractChainingPrintRenderer</exclude>
<exclude>org/xwiki/rendering/renderer/xhtml/
DefaultXHTMLImageRenderer</exclude>
<exclude>org/xwiki/rendering/renderer/xhtml/
DefaultXHTMLLinkRenderer</exclude>
<exclude>org/xwiki/rendering/renderer/xhtml/
XHTMLRendererFactory</exclude>
<exclude>org/xwiki/rendering/util/RenderersUtils</
exclude>
<exclude>org/xwiki/rendering/parser/SyntaxFactory</
exclude>
<exclude>org/xwiki/rendering/renderer/xhtml/
XHTMLImageRenderer</exclude>
<exclude>org/xwiki/rendering/renderer/xhtml/
XHTMLLinkRenderer</exclude>
<exclude>org/xwiki/rendering/parser/SyntaxType</
exclude>
<exclude>org/xwiki/rendering/macro/descriptor/
MacroDescriptor</exclude>
<exclude>org/xwiki/rendering/renderer/printer/
MonitoringWikiPrinter</exclude>
<exclude>org/xwiki/rendering/configuration/
RenderingConfiguration</exclude>
<exclude>org/xwiki/rendering/macro/MacroManager</
exclude>
<exclude>org/xwiki/rendering/block/MacroBlock</exclude>
<exclude>org/xwiki/rendering/macro/AbstractMacro</
exclude>
<exclude>org/xwiki/rendering/macro/descriptor/
AbstractMacroDescriptor</exclude>
<exclude>org/xwiki/rendering/macro/descriptor/
DefaultMacroDescriptor</exclude>
<exclude>org/xwiki/rendering/block/
PlainTextBlockFilter</exclude>
<exclude>org/xwiki/rendering/util/ParserUtils</exclude>
This will add some more.
Here's my +1
Thanks
-Vincent
Hi Vincent
>The easiest is really if you can upgrade your install on XE 2.0M3
>(latest trunk). FYI 2.0M3 should be released tomorrow (if all goes
>fine).
>
>We'd also love to get feedback on 2.0M3 (or latest trunk). We think
>it's pretty stable and nice but someone using it for real would be
>great to verify all is fine before the final release.
>
>You'd also wiki macros btw (amongst other things) ;)
I upgrade my life wiki on:
http://madplanet.com/xwiki
to 2.0m3 and it seems to run smoothly. Upgrading the Blog Feed works now and I can see the 2.0 Wiki blog entries nicely. The rest of the wiki seems to run much faster then previously even though I don't have hard numbers.
I'll let you know when something goes wrong.
Cheers - Andy