Hello!
I am working on a script service to provides better support for querying
groups of users. I would like to publish it as the api-user-group or
user-group-api extension, as you see fit. Please could you create a
repository on xwiki-contrib for this extension, my github user is pcojan.
Thank you!
Hi devs,
Can I be added as a committer on xwiki-contrib, please?
I plan to mainly work on application-task (already have a few pull
requests for it).
Thanks,
--
Jean
Since Marius wrote the FileManager application using AngularJS
and there has been some discussion about making increasing use
of it in XWiki, I wanted to share a review by someone who uses
it in his job as their entire platform.
These are advantages and disadvantages which I determined from the chat:
+ Easy and efficient workflow (when you know it)
+ Testing is easy and well understood
+ Debugging is not difficult, thanks to Angular's popularity and integrated software
+ Separates model and view well (makes angular apps skinable).
- Owns your system, if angular dies you die with it
- Learning curve
- Though it separates your model and view well, you can't test your model and controller without a DOM present (he's not sure of this).
Although I think we need to keep investigating, I feel that
Angular warrants more investigation.
Thanks,
Caleb
PS: And the actual conversation, including some useful links:
16:31 < cjd> gimme teh infoz
16:32 < SomeoneWeird> well, there's a lot of (maybe too much) magic going on behind the scenes
16:32 < SomeoneWeird> all the DI stuff, scope tracking
16:32 < SomeoneWeird> sticking one broken thing in the digest loop will kill the entire app
16:32 < cjd> /nod
16:32 < SomeoneWeird> but.. once you know how it works, it's great
16:33 < SomeoneWeird> it's entire stdlib is all promises (which I don't care for, but because it's ALL promises, it makes it a breeze to work with)
16:33 < SomeoneWeird> plus, the DI system is awsm
16:33 < cjd> ok
16:34 < SomeoneWeird> scoping it out because you wanna use it?
16:34 < cjd> xwiki is interested in it
16:34 < cjd> do you use it as a system to control your entire app or as a library?
16:34 < SomeoneWeird> it's our entire thing
16:34 < cjd> ok
16:34 < SomeoneWeird> our CMS is built up of multiple angular apps
16:34 < SomeoneWeird> which are nested
16:35 < cjd> how is it for debugging?
16:36 < SomeoneWeird> not terrible, the errors it gives up are sometimes broken (but we're using a slightly outdated version), but there's also batarang, which is a cool ext. so you can view scope contents in your browser
16:36 < SomeoneWeird> https://chrome.google.com/webstore/detail/angularjs-batarang/ighdmehidhipcm…
16:36 < cjd> ok
16:37 < SomeoneWeird> oh, testing
16:37 < SomeoneWeird> is awesome
16:37 < cjd> you can unit test in node ?
16:37 < SomeoneWeird> built in mocking support for everything in build in libraries
16:37 < SomeoneWeird> cjd: probably, using phantom or something
16:38 < cjd> ok, so you need a DOM to test
16:38 < SomeoneWeird> hm
16:38 < SomeoneWeird> i think
16:38 < cjd> ok
16:38 < SomeoneWeird> we're using karma at work
16:39 < cjd> explain?
16:39 < SomeoneWeird> http://karma-runner.github.io/0.12/index.html
16:39 < SomeoneWeird> check the vid
16:39 < cjd> ok
16:39 < SomeoneWeird> it's a test runner for browser tests
16:39 < SomeoneWeird> i think you can do headless stuff with it too
16:39 < cjd> how is the seperation between your models and the views?
16:40 < cjd> (is it skinnable?)
16:40 < SomeoneWeird> skinnable?
16:40 < cjd> could you write a new <fakehtml> view for a widget
16:41 < SomeoneWeird> yes
16:41 < cjd> so put a new skin on that widget
16:41 < SomeoneWeird> directives
16:41 < cjd> ok and you don't need to tinker with your model or controller code to do that?
16:41 < SomeoneWeird> models & views are pretty seperated, html can be completely declarative if you want
16:41 < cjd> ok
16:42 < SomeoneWeird> http://www.sitepoint.com/practical-guide-angularjs-directives/
16:42 < cjd> so summary:
16:42 < SomeoneWeird> so you can define <hello>, and then bind that to a model etc
16:42 < cjd> + easy and efficient workflow (when you know it)
16:42 < SomeoneWeird> but they're seperate until you do
16:42 < cjd> + testing is easy and well understood
16:43 < cjd> + debugging is not difficult, thanks to angular's popularity and integrated software
16:43 < SomeoneWeird> there is a definite learning curve though
16:44 < cjd> - Owns your system, if angular dies you die with it
16:44 < SomeoneWeird> especially if people are used to using jquery etc
16:44 < cjd> - Learning curve
16:44 < cjd> - Though it seperates your model and view well, you can't test your model and controller without a DOM present.
16:45 < cjd> anything to add?
16:45 < SomeoneWeird> i'm not 100% sure on the last point
16:45 < cjd> ok
16:45 < cjd> can I publish this conversation?
16:46 < SomeoneWeird> i guess, hopefully I'm not wrong about anything >.>
16:46 < cjd> ok :)
16:48 < SomeoneWeird> http://www.reddit.com/r/webdev/comments/1rbz0h/is_angularjs_worth_developin…
16:48 < SomeoneWeird> good points in here
Hi,
We did some usability testing sessions and found out that one of the
biggest problems users are facing is that they don't understand the Home -
Wiki - Space - Page concepts.
Because of this confusion:
- they are creating a wiki instead of a space or a page,
- they don't know where they are located when looking at a page (in the
main wiki or in a subwiki),
- they don't know how to navigate to the pages they've created,
- very confused that we have a Main space in every wiki,
- they are having a hard time making a difference between a space and an
application,
- hard to understand everything is a page,
- etc.
We could do many things in order to improve our navigation, but one thing I
want us to focus in this mail thread is the explanation of Wiki - Space -
Page concepts on the Main.WebHome.
Currently the content of the Welcome Block is:
= Welcome to your wiki =
>
> It's an easy-to-edit website that will help you work better together. This
> Wiki is made of //pages// sorted by //spaces//. You're currently in the
> **Main** space, looking at its home page (**WebHome**).
>
> Learn how to use XWiki with the [[Getting Started Guide]]
> You can then use the [[Sandbox space]] to try out your wiki's features.
>
I would like to replace this message with an introductory text that explain
the concepts (there were also some ideas that maybe we need some images to
represent the hierarchy, etc.) and I need your opinion on this subject.
So, how would you pitch the Wiki - Space - Page concepts to newcomers?
Thanks,
Caty
Hi,
FYI, I’ve completely modified the old XWiki Health Page at http://dev.xwiki.org/xwiki/bin/view/Community/ProjectHealth with new content and metrics.
I’ve started doing some analysis of the metric data I’ve found but I’d like to discuss those with you all and see if we agree on the reasons for the values found and then together decide if we want to do something about it and what.
Downloads
=========
One worry I have is http://dev.xwiki.org/xwiki/bin/view/Community/ProjectHealth#HDownloads It shows a reduction of downloads over the past 3 years, or, at best a stagnation. I’ve started the Active Installs module to get better feedback on this but at this moment it’s still to early since we have Active Installs history only since 6.1 (see the screenshot at http://extensions.xwiki.org/xwiki/bin/view/Extension/Active+Installs+Server…).
So are we really stagnating? Any idea why?
Mailing List Activity
=====================
http://dev.xwiki.org/xwiki/bin/view/Community/ProjectHealth#HMailingListsAc…
Also going down. Any ideas?
Am I reading these metrics right?
Other
=====
The other metrics are relatively ok. However I think these metrics show that the XWiki project is progressing at a stable rate both in term of usage (people using XWiki) and in term of code (# of commits, 1 of issues fixed every year, contributed code, etc).
So the question raised are:
- What could we do to increase the adoption speed of XWiki?
- What could we do to increase the code progression rate?
Which could be summed up as: what could we do to start having an exponential progression?
I have some ideas but I’d like to hear from others first to see what they think.
Thanks
-Vincent
Hi xwikiers! Here a new proposal about Icon Themes, that I would like to
introduce in XWiki 6.2.
Issue:
-------
In Colibri we use the "Silk" icons set. In Flamingo we want to use
monochromatic icons (font-based icon set). But we don't want to break the
retro-compatibility.
This proposal is only about improvements to the XWiki Syntax in order to
insert icons:
eg: image:icon:accept
The proposal is composed of A+B+C:
A - Create an icon set for XWiki
-------
As an API, XWiki proposes a selection of icons that developers can use. We
ensure to not break the retro-compatibility.
Actually, we do not create these icons. We bind them to existing ones (from
silk or whatever).
Example:
- accept
- cancel
- wiki
- user
- pdf
etc...
B - Create an Icon Theme
-------
Like the ColorThemes, we can create IconThemes. Concretly, for every icons
proposed in A), we create a mapping to an icon from Silk, FontAwesome, or
other icon sets.
Theme1:
accept: <img src="$xwiki.getSkinFile('silk/accept.png')" alt="accept"/>
Theme2:
accept: <i class="fa fa-check"></i>
C - Bind the Wiki Syntax to the current icon theme
-------
When a user writes:
image:icon:accept
it actually executes the mapping contained by the active IconTheme.
Here is my +1.
WDYT?
Thanks,
Guillaume
Hello People,
I am trying to insert the tags div in my class made through
appwithinminutes.
I already have inserted in the end of the sheet the template:
{{html}}#template('documentTags.vm'){{/html}}
But it not worked well, the "OK" button event is conflicting with the
preview button action. and it did not looked as well.See image attached.
Any ideas?
Is there a way to disable the preview button?
Thanks
--
Danilo Amaral de Oliveira
Engenheiro de Computação
celular (32) 9111 - 6867
Hello,
I would like to request the creation of a new account on nexus.xwiki.org to
be used for the release of extensions.
Desired username: vrachieru
Thanks,
Victor