Hi devs,
Under Anca's pressure (joking :)) here's a vote to upgrade our
velocity deps.
Reasons:
* There are some features listed below we want to benefit from
in the near future
* We have some lock issue with some velocity code in Velocity 1.5
on myxwiki.org and we hope (dream?) that the upgrade could fix them...
For details see http://jira.xwiki.org/jira/browse/XWIKI-3142
Note that the build works fine and the selenium tests seem ok
(although some tests are failing but some - all? - were also failing
before - this is bad btw since we can't trust our build, we need to
fix that).
Here's my +1
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net
Hi,
I suggest that we remove Calendar and PhotoAlbum applications from XE
default wiki.
Rationale:
- PhotoAlbum is almost unusable with HQ photos (basically any pic
taken with a digital camera) because of XE attachment management known
bugs.
- In their current state those applications doesn't meet XEs quality
requirements: test coverage, usability, performance (PhotoAlbum).
- Those 2 applications are orphan projects (no active project
leaders), btw anyone whishing to care of them is welcome.
Here's my +1.
JV.
Hi devs,
I posted a patch on http://jira.xwiki.org/jira/browse/XWIKI-3013 which
make XWiki authenticate only once by session by default, this is
configurable in xwiki.cfg using xwiki.authentication.always=1.
Pros:
- quicker navigation because user is not re-authenticated for each
request, this can be very annoying when authentication means access
another server like LDAP and when there is a lots of users at the same
time
Cons:
- you have to start a new session (by logout/login for example) to be
able to update informations from LDAP or any other authentication
which do data update from remote authentication server.
The cons is why I prefer to make this possible to disable if needed.
Here is my +1.
Thanks,
--
Thomas Mortagne
Hi,
I'd like to move calendar and photo album pages to their own
applications: xwiki-application-calendar and
xwiki-application-photoalbum.
xwiki-application-calendar pages :
- Main.EventCalendar
- XWiki.CalendarEvent
- XWiki.CalendarSheet
xwiki-application-photoalbum pages :
- Photos.Links
- Photos.NewAlbum
- Photos.WebHome
- XWiki.PhotoAlbumClass
- XWiki.PhotoAlbumClassSheet
- XWiki.PhotoAlbumClassTemplate
Here's my +1.
JV.
Hi,
I've worked on a new Dashboard for XE, you can see it at :
http://incubator.myxwiki.org/xwiki/bin/view/Main/WebHome
Note that it may differ a bit from my local version (fixed bugs,
improved styling, new tag plugin) but almost everything is there.
This new home relies on improvements in the tag application.
I'm still waiting for some CSS improvements from Laurent but I'd like
to commit it later this week.
Here's my +1.
Thanks,
JV.
Hi,
Silk icons is a 1000 icons set design for website and webapps.
Overview:
http://www.famfamfam.com/lab/icons/silk/previews/index_abc.png
In action:
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children
I'm pretty sure you've already seen them since they are becoming a
standard all over the web.
I think we should bundle them with XWiki [1] for 3 reasons :
1/ They're gorgeous!
2/ We're using icons coming from here and there in our applications
(RMUI, Blog, etc) and we're missing some consistency.
3/ Since XWiki is also a webapp development framework I think it would
be a good thing that it comes with a complete webapp icons set.
Here's my +1.
[1] I've mailed Silk author to discuss about licensing issues. I don't
know if bundling CCA2.5 licensed work within a LGPL package is
allowed.
JV.
Hi,
Now that Toucan has been up and running for more than 1 year what do
we do with the Albatross skin?
Several options:
1) We continue to support it and fix bugs such as http://jira.xwiki.org/jira/browse/XWIKI-679
2) We decide to mothball it, ie not support it ourselves but apply
patches from users if they come. This means keeping it in svn but not
packaging it with XE
I'm hesitating. Maybe we should poll our users list?
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net
Hi,
I'd like to move Tags related pages to their own app: xwiki-application-tag.
I'd also like to commit a small plugin that allows to manipulate tags easily.
It also avoid the need of programming rights on pages Tags and TagsRss.
The application and the plugin would have the same release cycle and would
be included in xwiki enterprise (like skinx or watchlist plugins/apps).
This also mean that we'll have a tag application in JIRA.
Tag pages :
- Main.TagCloud
- Main.Tags
- Main.TagsRss
- XWiki.TagClass
Tag plugin API :
public List<String> getTags(boolean distinct);
public List<String> getPagesWithTag(String tag);
public boolean renameTag(String tag, String newTag);
public boolean deleteTag(String tag);
Here's my +1.
JV.
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children
Note that this list comes along with a generic way of building
spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
2/ Add a getChildren() method to XWikiDocument and Document (API).
Rationale: XWiki is a wiki and the parent/child relationship should
be made more visible and easy to display in order to make it useful. I
know we should try not to put new methods in our APIs but IMHO this
should have been there from the beginning.
Proposal:
{{code}}
Document.java
public List<String> getChildren() throws XWikiException
{
return this.doc.getChildren(getXWikiContext());
}
XWikiDocument.java
public List<String> getChildren(XWikiContext context) throws XWikiException
{
String hql ="select doc.fullName from XWikiDocument doc " +
"where doc.parent='" + getFullName() + "' order by
doc.space, doc.name";
return context.getWiki().search(hql, context);
}
{{/code}}
Note: I've put doc.space and doc.name in the order by clause since
getting pages in the 'absolute' alphabetical order afterwards is easy
using util.sort while the contrary is not true.
Here's my +1
3/ Add a $blacklistedSpaces list in xwikivars.vm. Rationale: avoid
duplicates; this list is already present in some panels and pages
since it is a common need.
Proposal:
#set($blacklistedSpaces = ["Import", "Panels", "Scheduler", "Stats",
"XAppClasses", "XAppSheets", "XAppTemplates", "XWiki"])
Here's my +1
4/ Don't display the number of children in tab. Rationale: limit the
number of HQL queries made on the view action.
Here's my +1
Thanks,
JV.