The XWiki Development Team is pleased to announce the release of XWiki Enterprise 4.1 Milestone 2.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is the second and final milestone of the XWiki Enterprise 4.1 development cycle.
Changes from Milestone 1:
* Extension Manager now handles updates to configuration documents.
* New localization through timezone settings.
* Customization of chart colors.
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…
Thanks,
The XWiki Development Team
Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
Here is my +1.
Thanks,
--
Thomas Mortagne
Hi devs,
We have the need of a Configuration Source component hint for implementation that only looks in non-modifiable sources (e.g. xwiki.properties).
More specifically there's a security issue in some cases in allowing to use the current "default" configuration source which looks in space preferences, wiki preferences and the only in xwiki.properties.
For example the Environment's permanent directory should not be modifiable from wiki pages (see http://jira.xwiki.org/browse/XCOMMONS-182).
So here's the proposal:
* Introduce a new RestrictedConfigurationSourceProvider implementation (in configuration-api) that does the same as the current ConfigurationSourceProvider but when looking up the CS, it looks for a CS with hint "restricted"
* Deprecate the current XWikiPropertiesConfigurationSource (hint = "default")
* Add a new XWikiPropertiesConfigurationSource with hint = "restricted"
* Modify DefaultEnvironmentConfiguration to use:
@Inject
@Named("restricted")
private Provider<ConfigurationSource> configurationSourceProvider;
WDYT?
Thanks
-Vincent
Hi,
I would like to release M2 early tomorrow, if any developer needs to hold the release
to make a change, or has any questions, please reply to this mail before the end of today.
Thanks,
Caleb
Hi,
I know this is not a support list, but we found a bug that we consider
serious related to searching:
http://jira.xwiki.org/browse/XWIKI-7753
Since search is an often used function, we believe others have faced
this so I'd like to ask the most experienced ones if this bug is a real
bug, or we just misconfigured XWiki.
Thanks in advance,
Daniel Marczisovszky
Hi, all,
I am trying to add buttons on the wysiwyg or inline form editor toolbar, I
checked the wysiwyg gwt source code, and the wysiwyg.js file, I am more
toward add javascript code in wysiwyg.js file to add javascript code for
buttons on the toolbar, instead of adding java code for the plugin, any
suggestions?
Thanks in advance
Dave
Hello ,I wander if there is the js api document about the wysiwyg which I can use in client .I need to add a very very simple function to the wysiwyg in client.
but I only find some api I can use here!(I use xwiki 3.5)
http://extensions.xwiki.org/xwiki/bin/view/Extension/WYSIWYG+Editor+Module#…
Is there api in detail ?.In fact ,The most important thing is to add some HTML elements (just as div or button)to the xwiki document .It is very easy no matter in javascript or gwt(It is unable to use here because of some problems, so I have to implement it in client with js). But I don't know how to operate the xwiki document w't ith js,I even can't get it ,so .. A poor student with poor English and programming knowledge who have to develop the system by himself need your help .Thanks !
Why can't we offer the download of apis ? of it's just I havn't fount theml
Hello friends,
Thank you, glad to hear that I am getting somewhere
Here is a better version of the sidebar:
http://jssolichin.com/public/4/4.%20Home-alt.png
The boxes with the x will be icons. having those I think will help inform
the reader what is available, instead of the previous metro like overflow.
It will also allow a space for numbers showing how much content is
available in that section. When you hover over that section, it will still
reveal the hover nav in the last mock up to allow for easier clicking and
clarity (as to what the icons are):
http://jssolichin.com/public/4/3.%20Home-navhover.png
I know that the icons will not fit with longer section names like comments,
so the icon might be placed above the section name, or be smaller. On that
point, I would just like to mention that i'm hoping to also allow the
reader to resize the sidebar size fluidly. So if they are reading the
comments section, they can devote more space to it. This will, however, be
disabled in the mobile version.
* The way the navigation links are organized/grouped together is a bit
> weird (the upper part with wiki/space/page links)
>
Visually, I'm not sure if it came through in the wireframe, but i'm
imagining it like the iphone folder [1], where we have the breadcrumb/nav
(wiki/space/pages) always visible, then when the user clicks it, it reveals
the "watch page, access rights, etc." By iphone folder like i mean, it
pushes everything down and visually seems to reveal something underneath.
But that last point is trivial.
More technically, since the navigation is vertical, the breadcrumb style is
a bit unclear, and do need to be more refined. Right now i'm thinking
maybe a folder esque structure:
x wiki
\_ x space
\_x pages
but I feel like that might get to cluttered. Maybe we should just remove
the breadcrumb navigation and just have it like in the lyrebird where it
appears as part of the content and not as a "global nav?" What does the
community think?
* On the desktop you probably don't want that inner scroller, but
> rather have the right panel fixed and keep the page's natural scroll.
You're right, that would make sense. I think the right solution would be to
make the right sidebar scroll like the chatlist window on facebook where if
you hover over the area, it will reveal a scroll bar indicator to show your
vertical location and allow you to scroll that section using the mouse
wheel.
Do you guys think it will be ok that we do not have the up and down arrow?
or would that be bad usability. I personally think it will be fine since
even sites like gmail uses a non native scroll indicator without the up and
down arrow--it's just prettier.
The menu part still needs to be refined
Did I address it earlier in this email, or am I still missing something?
Can you clarify specifically which point for me to work at?
> Putting the menu on the left would be more familiar to mobile users (the
> > nav menu is usually on the right in all the mobile apps I regularly
> use).
> Maybe we don't want to be like every other app ;p
> I don't know, I think we can try it out on the right and see how it
> feels. Same for the desktop in fact ; though I think it's going to
> feel more natural on the right in that case.
I think both points are valid. I personally chose the right side because I
feel like when you land on a page, you want to read content first. But I do
know what you mean, left is the traditional side and is used in giant sites
like gmail, facebook, hotmail and so forth. I think we should get more
input on this.
> Jonathan: I don't remember whether Jérôme pointed you to his lyrebird
> work:
> >
> http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-cs…
> > it could be an additional source of inspiration for you.
> I don't remember I did.
> Let me fix the link :
>
> http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-css
> Also, sources are on github : https://github.com/jvelo/Lyrebird<https://github.com/jvelo/Lyrebird;cid=1338111304826-974>
Thank you, this will be a wonderful resource!
Let me know what you guys think.
Best,
Jonathan Solichin
[1] http://media.tecca.com/2011/02/17/mh-630-iphone-folder-header-630w.jpg
Hi devs,
For the new messageSender macro [1][2], I chose the name using the
"attachmentSelector" macro as a template: "<object><personified-action>"
Vincent did not really like the "messageSender" name and proposed
"message", "sendMessage" or "userMessage".
Since AFAIK we don`t currently have a naming convention for wiki macro
names, I`d like to propose that we stick to the patterns:
1) "<object><personified-action>" (attachmentSelector, messageSender) for
action-oriented macros and
2) "<object(s)>" (documents, spaces, activity) for display-oriented macros
For 2), it's pretty clear, but for 1), I personally prefer
"<object><personified-action>" since overall it is a noun and, in english,
the phrase "messageSender macro" sounds better to me than "sendMessage
macro". Also, I think that the main action of the action-oriented macro
should be reflected in its name.
I`d like your opinion on the matter and also new proposals if you have any.
Here's my +1 for 1) and 2).
Thanks,
Eduard
----------
[1] http://xwiki.markmail.org/thread/mxpkpqfplbznfgbd
[2] http://jira.xwiki.org/browse/XWIKI-7679