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
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.6 Milestone 1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
First milestone of the XWiki Enterprise 1.6 version.
Main changes:
* New experimental support for other syntaxes (Confluence, JSPWiki,
Creole, MediaWiki, TWiki and XHTML), including a new XWiki Syntax v2.0
(work in progress, see XWiki Syntax 2.0 Draft). More information about
this in the release notes.
* New experimental WYSIWYG editor (Work In Progress). More
information about this in the release notes.
* Improved page footer displaying : comments, attachments, history,
various informationpagebottom.png
* New "Password Renewal and Forgot Username" feature
* Default account validation & confirmation emails provided in the
wiki preferences
* Added .xml extensions to all exported wiki pages (XAR)
* The generated HTML for wiki titles now start at h1 instead of h2
* New or improved translations: german, french, czech, norwegian, ukrainian
* The name of the main database in virtual wiki mode is not hardcoded
to 'xwiki' anymore, and in virtual mode all database names can be
prefixed with a configurable value
Important bug fixes:
* Use of "." in LDAP logins fixed
* Various fixes in the watchlist:
** Watchlist now works with platform 1.5 and 1.6
** Fixed rights checks in multiwiki mode
** Fixed RSS feed generation in multiwiki
Note that general goals for XWiki Enterprise 1.6 are:
* Beta versions of new rendering + new WYSIWYG editor
* Revamped Blog UI + features
* Security issues already in JIRA (marked as high priority)
* Bug fixes
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise16M1
Thanks,
The XWiki dev team
Greetings
My objective is to list every document with some tag (e.g. "MainTag"), and next, select all tags of these
documents without repeating any of them (including "MainTag").
I tried to merge the next two queries but without sucess.
This query selects every document that have the tag "KB-4D":
#set($sql = ", BaseObject as obj, DBStringListProperty as prop where obj.name=doc.fullName and
obj.className='XWiki.TagClass' and obj.id=prop.id.id and prop.id.name='tags' and 'KB-4D' in
elements(prop.list) order by doc.name asc")
#set ($list = $xwiki.searchDocuments($sql))
This query selects every tags present in the documents listed by the previous query:
#set($sql = "select distinct elements(prop.list) from BaseObject as obj, DBStringListProperty as prop where
obj.className='XWiki.TagClass' and obj.id=prop.id.id and prop.id.name='tags' and obj.name='$item'")
#set ($tags = $xwiki.search($sql))
Can anyone help me with this?
Thanks in advance
Bruno Neves
PS: How can I put snippet code on code.xwiki.org? I need to login but I am not registered.
I'm crossposting to dev because it's interesting for xwiki developers
We thought already of this for attached files. But indeed it would be
good for scripts.
So we could have an export option where the attached file, the wiki page
content is separated from the XML to make it editable.
To be able to do that for script files, we first need to have this meta
field that tell us it's a script (and also that requires programmers
rights for example).
Ludovic
David Ward wrote:
> Paul,
>
> On Fri, Aug 29, 2008 at 3:19 PM, Paul Libbrecht <paul(a)activemath.org> wrote:
>
>> Here's a tiny idea:
>> currently all the files that need programming rights are velocity or groovy
>> files.
>> Well... let them be considered as such!
>> - the archive or the file-sync-storage should call them .vm or .gvy
>> - they should not be in XML format but in raw source format
>> - say, for CreateResources/SimpleWikiResource, that would be a file called
>> SimpleWikiResource.vm in CreateResources directory
>> - of course, such pages would be loaded with programming rights so
>> give-prog-rights should not exist anymore
>>
>> Because they are raw files, we're loosing abilities such as attachments and
>> a few other things that the XML format can represent (e.g. parent file).
>>
>
> Unfortunately they would lose quite a few things:
> - parent page (as you mentioned, which is used for the bread crumbs)
> - page title (also used for the bread crumbs, as well as other places)
> - rights (** quite important for restricting access, allowing access
> for some, etc.)
> - attachments (which sometimes hold images for that page)
> - objects (which sometimes hold various things)
>
>
>> But we're gaining:
>> - IDE friendliness (huge to my taste)
>> - auto-programming-rights
>>
>
> Yes, the IDE friendlyness (plus MUCH better version control
> possibilities) is a big item on my list.
>
>
>> One could even add a file-type .xwk for wiki source files (no programming
>> rights).
>> Oh, and one should agree on an encoding here... guess what I propose utf-8.
>>
>
> Yes, UTF-8 is probably the best encoding.
>
>
> You can see the thoughts I put down a while ago at
> http://dev.xwiki.org/xwiki/bin/view/Design/AlternativePageStore
>
>
> David
> --
> _______________________________________________
> curriki-devs mailing list
> curriki-devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/curriki-devs
>
>
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi,
Since the XE 1.6 release is planned for the 22nd of September, I think
it would be good that we plan the 1.7 release for Javapolis 2008
(around the 10th of December). That leaves a bit more than 2 months so
we could have:
- 1.7M1: 20th of October (that's more than 3 weeks after the 1.6
release)
- 1.7M2: 10th of November (3 weeks after 1.7M1)
- 1.7RC1: 17 Nov (one week after)
- 1.7RC2 or final: 24 Nov (one week after)
- 1.7 final (if needed): 1st of December
We could have the following for it already:
1) fully operational new WYSIWYG + new rendering
2) working JCR implementation + Query Manager
3) office import/export integrated into XE and in the new WYSIWYG
4) finished full revamping of the blog application
And more... (Please Add below)
The most important feature will be the new WYSIWYG that we will be
able to showcase at Javapolis.
WDYT?
Thanks
-Vincent
hai ,
i need to export image as a pdf , but that image in other document.how can i
export that one?
ex:
i have attached a imege in page1 (document name),
and i have added the content <img src=
http://localhost:8088/xwiki/bin/download/page1f/firsthome.jpg> in page2
(document name)
i need to export PDF in page2 with image
regards
sekar..
Hi David and Ludovic,
I have finished implementing the second method proposed to achieve the
distributed search of XWiki.
In method I, the master node search the individual indexes each XWiki
Installation.
In method II, the master node maintains a global index of all the other
XWiki Installations and searches on it.
the code has been committed here
https://svn.xwiki.org/svnroot/xwiki/sandbox/plugins/distributedSearchMethod2
Implementation details of both method I and II are presented in detail @
http://dev.xwiki.org/xwiki/bin/view/Design/DistributedXWikiSearchEngine
---
Sai Krishna
Hi Sergiu,
This test that you wrote has failed on Hudson:
public void testTimeComplexity()
{
ArrayList<String> tests = new ArrayList<String>();
ArrayList<String> expects = new ArrayList<String>();
// Something like this should be (negatively) matched in
linear time, thus it should take no
// time. If the build takes a lot, then the regular
expression is not in linear time, thus
// wrong.
String text = "*";
for (int i = 0; i < 1000; ++i) {
text += "abc *";
}
tests.add(text);
expects.add(text);
long startTime = System.currentTimeMillis();
test(tests, expects);
// Even on very slow systems this should not take more than
one second. Putting 10 seconds,
// just to be sure we don't get false test errors.
assertTrue(System.currentTimeMillis() - startTime < 10000);
}
Result here:
http://hudson.xwiki.org/job/xwiki-platform-core-trunk/com.xpn.xwiki.platfor…
So it seems it took more than 10 seconds.
Does it mean the code is not working?
What should we do?
Thanks
-Vincent
Hi Marius,
Is this still needed? Can we remove it now?
Thanks
-Vincent
On Aug 22, 2008, at 4:56 PM, mflorea (SVN) wrote:
> Author: mflorea
> Date: 2008-08-22 16:56:13 +0200 (Fri, 22 Aug 2008)
> New Revision: 11972
>
> Modified:
> platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/
> resources/xwiki.cfg.vm
> Log:
> XWIKI-2497: I added the xwiki.wysiwygnew parameter in order to
> enable/disable the new WYSIWYG editor.
>
> Modified: platform/xwiki-tools/trunk/xwiki-configuration-resources/
> src/main/resources/xwiki.cfg.vm
> ===================================================================
> --- platform/xwiki-tools/trunk/xwiki-configuration-resources/src/
> main/resources/xwiki.cfg.vm 2008-08-22 14:44:31 UTC (rev 11971)
> +++ platform/xwiki-tools/trunk/xwiki-configuration-resources/src/
> main/resources/xwiki.cfg.vm 2008-08-22 14:56:13 UTC (rev 11972)
> @@ -236,4 +236,9 @@
> #-# Add a prefix to all databases names of the wikis in virtual mode
> and to the wiki name in non virtual mode
> # xwiki.db.prefix=
>
> +#-# [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
> +
> $!xwikiCfgAdditionalProperties