Hi,
Please don’t post on the notifications and devs mailing lists. Those are reserved mailing lists.
Please repost on the forum instead, see http://dev.xwiki.org/xwiki/bin/view/Community/Discuss
Thanks
-Vincent
> On 30 May 2017, at 19:34, andreea.avram22 <andreea.avram22(a)yahoo.com> wrote:
>
>
> Hi,
> I created a class with more attributes which represent the columns of a table. I need to write data in that table and also to get data from the table such that i will can compute an average for example (with that values) and after that i want to put/write the result in the same table.
> The page I have created using the class contains the attributes of the class, which I can modify, but I need the table.
> So, my question is:
> How can I make the table such that I will can write in it and get data from it? Also, how can I export that table as pdf document?
>
> Thank you!
>
> Trimis de pe smartphone-ul meu Samsung Galaxy.
The XWiki development team is proud to announce the availability of XWiki
9.4.
This releases is mostly focused on usability improvements. It adds support
for batch restore of deleted pages from the recycle bin. The content menu
has received some polishing. The live notification system has been improved
to group similar notification messages and to show notifications for page
comments. The history of an extension page now includes a special revision
that corresponds to the extension version so it is easier to "reset to
factory defaults". Finally, the Help Center and the Menu application are
now part of the default XWiki distribution.
As usual, this version also brings bug corrections.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.4/
Thanks for your support
-The XWiki dev team
Hi everyone !
By working on XWIKI-14289 (https://jira.xwiki.org/browse/XWIKI-14289), I
found out that the WatchList extension currently uses deprecated
features of the ActivityStream extension such as ActivityStreamPlugin
and ActivityStreamPluginApi in order to render events as a proper RSS feed.
As using deprecated APIs isn’t the perfect way to extend the platform
features, I was thinking about adapting the RSS feed management
capabilities currently present in the ActivityStream to the EventStream
extension. This would allow us to progressively move the internal event
management of the platform to the EventStream.
What do you think ?
FYI, the question of "What should we do of the ActivityStream extension
?" has already been raised here :
http://xwiki.475771.n2.nabble.com/Proposal-Implement-a-Notification-Center-…,
but didn’t came to a clear conclusion. It could also be nice to finally
decide how we want to share the platform event management system between
the EventStream and the ActivityStream.
Thanks,
--
Clément Aubin
Web Developer Intern @XWiki SAS
clement.aubin(a)xwiki.com
More about us at http://www.xwiki.com
Hello. I've made a class with some properties and some pages as well, following the steps in the documentation. Now I want to
access those pages and their properties (which have values) from another page and I can't figure out how. I
tried the code from http://platform.xwiki.org/xwiki/bin/view/DevGuide/APIGuide#HAddobjectstoapa…
but it doesn't seem to work (it can't find the object or see the values). I also don't quite grasp the difference between
space, page, document and object.
Hi devs,
A while ago GitHub introduced several features that I think can help
boost even more the code quality, reduce the bus factor, and make it
more attractive to contribute to the project.
= Protected branches =
Branches can be configured as protected in several ways:
* Require pull request reviews before merging
** no direct commits are allowed, everything must go through a pull request
** a pull request must be reviewed by at least one other trusted
committer before it is allowed to be merged
* Require status checks to pass before merging
** pull requests must pass automated checks, for example by being
successfully built by a CI service
* Restrict who can push to this branch
** official branches (master + stable-x.y) could be restricted to
approved committers, but we could grant write access to all other
interested developers more easily
= Reviews for pull requests =
Comments on all commits as well on pull requests have been supported
since the early days of GitHub, but more recently it is easier to submit
(and request) actual reviews for pull requests. Instead of simply
commenting, and changing that special field on Jira, an official pull
request status is supported, with three states:
- review required
- changes requested
- approved
PR authors can either await for reviews from anybody, or request someone
in particular for a review.
Committers can filter PRs by their status, and they can also show only
the PRs that require their review.
= Getting more eyeballs on the code =
As Linus' Law states, "given enough eyeballs, all bugs are shallow".
We've been experimenting with mandatory pull requests for a while in my
other XWiki-based project, with great success so far. So here's a
proposal for a different development workflow:
1. Set up 2 teams, one with master (senior) committers, fully vetted
committers that have proven they understand the XWiki code, as well as
the XWiki product, and one with junior committers
2. Protect the master branch. Require pull requests and reviews before
any code is merged in it. Restrict push only to the master committers.
3. Everybody works on separate branches
4. Once the code is almost done, make a pull request and require reviews
from two junior committers
4a. Or, instead of requesting, let committers volunteer themselves, but
it's less likely that someone will volunteer on time
5. The junior committers must then carefully review the code, and either
require changes, just comment, or approve the pull request
6. Once the junior committers have approved the pull request, the PR
author must request review from a senior committer
7. The senior committer can either approve and merge the pull request,
or send it back to step 3.
e. We can define allowed exceptions: don't require PRs from senior
committers if the fixes are really small and obvious, like fixing typos,
or small and important bugfixes that must be merged quickly, but these
should really be rare exceptions
While it does sound like more work for an already overworked team, this
has many benefits:
* the code will have better quality
* awareness of:
** what's new / changing
** how others are approaching a problem (especially juniors learning
from seniors by being exposed to more code)
** the existing code, since the codebase is large and otherwise people
have few occasions to look at many of the parts of XWiki
* this means a larger bus factor for new code, and slowly increasing it
for existing code that's being touched by one and reviewed by many
* theoretically, less time spent doing reviews, since all committers
should look over every commit anyway, but this way they are explicitly
told when they should look, instead of wasting time reviewing work in
progress
* larger community, since people can more quickly become junior
committers instead of having to invest many months of years of forkwork
before committership
* easier collaboration on code, since it's very hard to work on someone
else's fork branches, but easy to work on an origin branch
So, what do you think?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
We have this jira issue I created a while ago and I’d like to move forward:
https://jira.xwiki.org/browse/XWIKI-13101
I have one question:
Should we move the 4 pages into a legacy module in platform and bundle it in XE or just remove them?
My POV:
We could consider the pages as APIs I guess and use the API strategy of moving deprecated APIs to legacy.
WDYT?
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki
9.4 Release Candidate 1.
This release adds support for batch restore of deleted pages from the
recycle bin. The content menu has received some usability improvements. The
live notification system has been improved to group similar notification
messages and to show notifications for page comments. The history of an
extension page now includes a special revision that corresponds to the
extension version. The Help Center and the Menu application are now part of
the default XWiki distribution.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.4RC1/
Thanks for your support
-The XWiki dev team
Hi,
I recently made some changes in the the XWiki platform repo to solve the
following bug:
https://jira.xwiki.org/browse/XWIKI-12869?jql=Difficulty%20%3D%20Easy%20and…
Although the changes seemed obvious, but I was not able to verify those
changes on my running XWiki instance.
As far as I know, if I make some changes to an application (for eg 'Blog
Application') on my computer, and then build it, then a '.xar' file is
generated which can be imported to my local XWiki instance and I can verify
visually whether those changes took place or not.
In my present case I made changes in
'xwiki-platform/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/editclass.vm'.
I thought a xar file of xwiki-platform-flamingo-skin will be generated if I
build xwiki-platform-flamingo, but it didn't take place.
Is there any way in which I can verify these changes on my local XWiki
instance?
Thanks :)
Sarthak Gupta