Some open issues/questions:
1) I think we need a syntax for escaping a block of text. I'd propose
using {{{whatever here}}} (same as creole and confluence). We could do
it with a macro but I don't know how we could implement it easily...
2) Do we want double curly braces for macros or simple ones:
{{macro/}} or {macro/}. If we use simple ones then it won't be easy to
enter { and } chars in a text (they would need to be escaped) and
since we've decided to have double chars for items ( **, --, ~~, etc)
we might as well do that for macros.
3) Do we want to support images in links. For example:
[[image:someimage.png]]? We already support URIs in links, such as
mailto: so maybe it wouldn't be too hard to support images too I
guess. Or do we want only the Image macro? A related question is do we
support http images (http://.../someimage.png) inside links and as an
inline element directly in the text?
4) Tables: do we keep the table macro or do we want a wiki syntax for
tables.
Thanks
-Vincent
just in case this is useful for us:
http://javascriptly.com/2008/08/yui-30-changes-from-the-root/
"
5 goals:
• Lighter (less K-weight on the wire and on the page for most uses)
• faster (fewer http requests, less code to write and compile, more
efficient code)
• more consistent (common naming, event signatures, and widget APIs
throughout the library)
• more powerful (do more with less implementation code)
• more securable (safer and easier to expose to multiple developers
working in the same environment; easier to run under systems likeCaja
or ADsafe)
[...]
So, what’s new in YUI 3.0? Many things, both large and small like:
• Intelligent loading. YUI detect which modules it needs to load, and
then download them from a server — it will also join the modules’
JavaScript source files together, in order to optimize download time.
• Change to a “YUI” namespace instead of “Yahoo” namespace in YUI 2.x
branches.
• Combine DOM events with custom events, making it possible to work
with all events in a unified way.
• Borrow “selectors” idea from JQuery to allow finding and working
with nodes on an individual and group basis.
• Chaining - another JQuery’s idea that makes it possible to write
more compressed chaining syntax in implementation code.
"
Thanks
-Vincent
Hi All,
I have created new Wiki using Wiki Manager and installed the enterprise and
administration page xar into it and get access to it using new domain url.
Now in which watchlist is not working for the newly created wiki.
The frequency set by default as "never", if i try to change it to hourly
means it wont get saved. Any work around for this issue.
Regards
Ambika
Hello.
Here is the list of URL patterns used by the RESTful API: http://dev.xwiki.org/xwiki/bin/view/Design/RestfulAPI . Everything that's on this page it's working, but I haven't found time to write full tests for them.
You can't just yet create an attachment, create and delete a class property, create an object and update an object property.
Thanks,
Alex
Dear devs,
Since XWiki 1.2, a rights inheritance mechanism is available in XWiki
that allows to make a wiki space have the exact same rights (inherited)
as it's parent space, defined as a WebPreferences ("parent" property of
the XWiki.XWikiPreferences object). This mechanism has to be activated
adding "xwiki.rights.maxrecursivespacechecks=1" to xwiki.cfg
I propose we enable this as a default setting. This is very usefull when
developing applications in XWiki for example (example: to have MyAppCode
inherit XWiki).
I see two ways of doing it :
1) We make "1" being default returned value in the java code when the
property is not defined in xwiki.cfg, and document the use of
xwiki.rights.maxrecursivespacechecks to disable the mechanism, or to
allow more levels of inheritance (2, 3, etc.)
2) We add xwiki.rights.maxrecursivespacechecks=1 to xwiki.cfg
I prefer way 1) and am +1 for it
WDYT ?
Regards,
Jerome.
On Mon, Sep 1, 2008 at 6:09 PM, SVN mflorea
<platform-notifications(a)xwiki.org> wrote:
>
> -#-# [SINCE 1.6M1]
> -#-# Enable the new, experimental, GWT-based WYSIWYG editor.
> -#-# It will be accessible by having 'editor=wysiwygnew' in the query string of the edit URL.
> -xwiki.wysiwygnew=1
> -
Since 1.6M1 has been released it should be marked as [SINCE 1.6M2].
Thanks,
JV.
Hi,
Since we've reorganized our products into projects I'm now proposing
that we change their group id from "com.xpn.xwiki.products" to
"org.xwiki.<project>".
Note that we're already using org.xwiki.platform for the platform
project.
Note also that this means rename org.xwiki.eclipse to
org.xwiki.xeclipse.
Here's my +1
Thanks
-Vincent
Hello XWikiers,
I am really surprised that there's no variant of
$xwiki.getURLContent(url)
which simply streams in place.
Since we are in velocity where interpretation is streaming, it would
appear natural that such a macro is also streaming, or?
paul
Hi,
I tried to use the new WYSIWYG editor in 1.6M1. I found some issues.
1) The new wysiwyg don't handle multi-level list correct. When I edit
a multi-level list in wysiwyg and save. The multi-level became flat.Is
this related to the xhtmlparser?
2) I type some letters and set them to strike format( the same for
bold, underline and italic). Then I want to type some new works who is
format is not strike. I just can't do this. All the words I typed
after is strike.
--
Thanks
Wang Ning