Fabio,
I would be eager to test it, especially with the changing java
architectures on the mac nowadays (basically the 64-bit/32-bit
switch). As soon as you have a release candidate I'll give it a try.
paul
Le 26-nov.-08 à 17:23, Fabio Mancinelli a écrit :
> Dear all,
>
> I would like to release XEclipse soon. During the last days I've fixed
> many of the outstanding bugs thanks also to the effective
> collaboration
> of Eduard Moraru who provided a lot of patches and I think that now
> XEclipse is pretty stable, usable and functional.
>
> This release incorporates a lot of features that have been implemented
> during the last months. In particular a better integration with the
> Eclipse ecosystem, object editor, translation management, page
> history,
> syntax highlighting and completion (thanks to the work done by Malaka
> during the last GSoC and Venkatesh) and many other improvements.
>
> There are still many things to do but I think that it's a priority to
> have a new version out asap in order to have more feedbacks from users
> and to build upon it.
>
> Due to some previous engagements I think I will be able to release
> it on
> Friday or during the weekend.
In a previous thread we've discussed about how to add a link in the
WYSIWYG editor, and more generally, how to browse the wiki from a
WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn
for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to
suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced
tree menu.
I've put the mockups and Pros/Cons on this wiki page :
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer
This wiki explorer widget would be used in the link dialogs, image
dialogs, file (attachment) dialogs.
Here's my +1 for 3) A).
+1 for 3) with filter option.
>From the implementation POV 3) is probably the most difficult proposal
and 1) the simplest one. Widget 3) would need to be a reusable (and
highly configurable) GWT component so that we could use it as our main
navigation/reorganization tool in the future. This tree would replace
our current treeview (Main.AllDocs) which is AFAIR the only page using
the YUI library in XE.
Thanks,
JV.
Hi devs,
I just finished a feature to be able to use mutiwiki without any use
of virtual host (ans so no need for a configured DNS server). It does
not replace the DNS based multiwiki it just add another way to access
subwiki so you can still use both. However all the URLs will be
generated in a way or another depending if urlpath is enabled or not.
So basically it add the possibility to access the wiki "wikiname"
using http://127.0.0.1/xwiki/subwiki/wikinname/view/Main/WebHome.
See http://jira.xwiki.org/jira/browse/XWIKI-2824
Normally I would wait for 1.8 branch to commit this but we have an
internal need for it to be included in the 1.6 branch (and if it's
included in 1.6, why not include this in 1.7 ;)).
Can we include it safely in 1.6/1.7 ? : it should be, if you don't
enable xwiki.virtual.urlpath in xwiki.cfg (and it will be disabled by
default), all will work exactly like this feature did not exists.
Here is my +1
Thanks,
--
Thomas Mortagne
For a new user will be best just to have an "Insert link" action.
If the link is external - default behavior
is internal - transparent (like an external one - but parse the URL for
advanced editing, letting user browse wikis, spaces)
After editing:
new page inserted exists - change the link
the page doesn't exist - create the page + change the link
See the image:http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterf…
The actions are just sketched, all the thinks previously discussed can be
inserted.
So, the idea is to take the URL and break it in
<wikiName>:<SpaceName>.<PageName>
if you need this format for further browsing and editing. This way you let
beginner user to insert a link in one step.
Thanks
Observation: When clicking on [Space Name > "Features"] the E dialog
appears.
Hi Devs,
xwiki-webdav-plugin was developed to provide means to calculate webdav urls
of xwiki documents and attachments. But as it turns out, for a given
document or an attachment, calculating webdav url is simply a string
manipulation operation. It doesn't require any support from the webdav
component (and thus the webdav plugin). So, I'm thinking we should remove
the webdav plugin completely.
WDYT ?
Thanks.
- Asiri
Hi,
There is a major discrepancy in the way the programming rights are
evaluated for the access to the privileged API from velocity compare
to the right to execute groovy code.
In the API, the right to access a priviledged API is evaluated against
the sdoc in the current context, which is the document that contains
the currently executed velocity code. Here is the code extracted from
the current RightService implementation that does so:
public boolean hasProgrammingRights(XWikiContext context)
{
XWikiDocument sdoc = (XWikiDocument) context.get("sdoc");
if (sdoc == null)
sdoc = context.getDoc();
return hasProgrammingRights(sdoc, context);
}
In the XWikiGroovyRenderer, the right to render a groovy code is
evaluated against the content doc, which is the top-level document
that have directly or indirectly included the document that contains
the evaluated groovy code. Here the excerpt from the code that made
this check:
if (!
context.getWiki().getRightService().hasProgrammingRights(contentdoc,
context)) {
return content;
}
These are two opposed methods.
As a direct consequence, a Sheet document (ie XWikiUserSheet) may be
developed in velocity and use the priviledged API, but it is
impossible to put a single line of Groovy in it, since the "instance"
of the template documents that include the Sheet are usually created
by users without programming rights.
The debate is now, what is the original or current intend. Do you want:
1) to have a very secure situation, and therefore change
hasProgrammingRights() implementation (why do we have a sdoc than?), or
2) to have a flexible, more responsible solution, were user having
programming rights should take care not writing risky code, and
therefore change the groovy renderer to accept groovy code based on
contextdoc (sdoc in that place), so groovy and velocity gets the same
access level ?
The current situation is for me not acceptable, since it is a mix of
1) and 2) depending on the language, and there is no reason that the
language influence the rights you have.
Thanks for your comments...
Denis
--
Denis Gervalle
SOFTEC sa
http://www.softec.st
hi,All
I have a question about the xwiki table usage.When I have a table ,I try
to split one cell to more cells or merge some cells into one cell,I find
this function is invalid,when I click the save button ,the saved table is
not what I want,is anybody know how to solve this issue?or anyone who has
the same problem?is xwiki support this syntax?if so,who has the xwiki script
for the table?
Thanks
Steven
Hi !
I installed recently the 1.6 version of XWiki and found that a new
functionnality allows to add logical groups to the group members list :
great ! This recursive inclusion is properly managed in global rights (like
allowing a global group for accessing a space) but this does not seem to be
included in velo xwiki API. For example I have one client that belongs to
its company group XWiki.MyClientCompanyGroup that I added to the group
XWiki.Clients. I have a dedicated part of my menu for clients and I tests
whether the current user is a client or not with the test
`$xwiki.user.isUserInGroup("XWiki.Clients")` which always return false :(
Maybe a special macro could help... anyone has a clue ?
--
Hoani CROSS
Globotraders Tahiti Founder [http://globotraders-tahiti.com]
Dear all,
I would like to release XEclipse soon. During the last days I've fixed
many of the outstanding bugs thanks also to the effective collaboration
of Eduard Moraru who provided a lot of patches and I think that now
XEclipse is pretty stable, usable and functional.
This release incorporates a lot of features that have been implemented
during the last months. In particular a better integration with the
Eclipse ecosystem, object editor, translation management, page history,
syntax highlighting and completion (thanks to the work done by Malaka
during the last GSoC and Venkatesh) and many other improvements.
There are still many things to do but I think that it's a priority to
have a new version out asap in order to have more feedbacks from users
and to build upon it.
Due to some previous engagements I think I will be able to release it on
Friday or during the weekend.
WDYT?
-Fabio
____________________________________