Hi devs,
I'd like to suggest we use {{dashboard style="colortheme"/}} by default on the main dashboard for the following reasons:
1) the default style has a heading size issue and it's hard for the dashboard to guess the correct size in all situations
2) it clearly shows it's a dashboard
WDYT?
Thanks
-Vincent
Hi devs and everyone,
Emilie has proposed the following content to be added to the Download page (http://www.xwiki.org/xwiki/bin/view/Main/Download):
http://dev.xwiki.org/xwiki/bin/view/Drafts/TextDownload
The idea is twofold:
1) to get feedback about what people think about our software.
2) some people who download the XWiki software from xwiki.org don't know that XWiki SAS has a commercial offerings and could be interested by it
The pros for the community are:
1) XWiki SAS will publish back the result of the feedback it receives from the download form which will allow us to fine tune and improve the software
2) XWiki SAS could get more business (from people who want to buy support, dev work, hosting, etc) which will mean accrued budget for paying developers and resources to work on the XWiki project
Note 1: the form would be of course optional
Note 2: in the future I'd like to see a not for profit foundation to handle xwiki.org, the xwiki open source project, donations, etc. When this happens we could elect from member for the foundation and have the feedback form sent to that foundation for example, with members of the foundation having access to the data (for example).
WDYT?
Thanks
-Vincent Massol, acting as both CTO of XWiki SAS and XWiki open source developer
Hi,
Just a notice that I'll remove the following branches from jira since we (open source xwiki developers) only support 2 branches (trunk + latest stable):
• xwiki-core-1.5-curriki/
• xwiki-core-1.8/
• xwiki-core-1.9/
• xwiki-core-2.1/
• xwiki-core-2.2/
• xwiki-core-2.3/
• xwiki-core-2.4/
Please shout quickly if you have a good reason to keep one of these (also note that they'll always be in the svn history).
Thanks
-Vincent
Hi,
Would be very nice to have a development wiki in order to get things going
on the new XWiki.org proposal:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2
Maybe Vincent can help with this? :)
Since the redesign is quite big and lots of spaces|panels|styles need to be
changed, morphing the current xwiki.org on the go would be quite difficult.
So, having the development wiki would be much easier to work decentralized
on different parts of it when people have time.
There are lot of areas of the proposal that are not covered and would be
really great to receive proposals and help from other members of the
community.
Also the implementation needs volunteers :) so any help is appreciated. We
will also use the new xwiki.org logo proposed by the community, so having
all this ideas come together and be put into action is very exciting.
Thanks for the support,
Caty
Resources:
- Original Proposal mail: http://markmail.org/message/4erqdhwuzvmtts6p
- Logo Challenge mail: http://markmail.org/thread/bze35tdm4iojnafa
Hi devs,
While designing the xwiki-action and xwiki-url modules I've realized that we need a general way to represent an xwiki resource and an action on that resource.
This will allow every resource in XWiki to be addressable and offer a generic action mechanism.
What is an xwiki resource?
=====================
Examples:
* an Entity (Document, XObject, XProperty, Attachment, etc)
* A Page (i.e. an Entity rendered with a skin)
* a resource file on the filesystem (image, css, js, icon, etc)
* something on which a REST call will operate (which may or may not be an Entity)
Note that a resource has a type, a reference and optional generic parameters. It's very much similar to a URI in the JDK but represented differently.
What is an action done on a resource?
=====================
Examples:
* For an Entity: view it in XHTML (or in any other syntax)
* For an Entity: view it with the skin applied, in XHTML (or in any other syntax)
* Generate a URL for it
* Create a link to it
* For an Entity: Create it, modify it, delete it
Where would it be used:
=====================
Examples:
* To transform any XWiki URL into a resource object. Any XWiki URL would be transformed internally into a resource. Note: The current XWikiURL class located in the xwiki-url module would disappear
* In the Rendering to represent the reference of a link or an image. Ex: [[label>>reference]]. We currently have a ResourceReference class that would be removed and replaced by the new generic resource class.
* More generically Resource and Resource Actions will be used at entry points of XWiki and internally XWiki will only manipulate Resources.
String representation:
=====================
<resource type>:<action>:<resource reference>
Examples:
=====================
* view a document with skin applied
page:view:wiki:space1.space2.page
<==> ViewAction
* view a document
entity:view:wiki:space1.space2.page
params: context=new
<==> No equiv or {{include document="wiki:space1.space2.page" context="new"/}}
ex: link to attachment
entity:link:wiki:space.page@my.png
<==> [[attach:wiki:space.page@my.png]]
ex: link to a document
entity:link:wiki:space1.space2.page
<==> [[doc:wiki:space1.space2.page]]
ex: view icon
icon:view:accept
<==> image:icon:accept
ex: view image stored in document
entity:view:wiki:space.page@my.png
<==> image:doc:wiki:space.page@my.png
ex: view image located at external URL
url:view:http://server/my.png
<==> image:url:http://server/my.png
API
===
* ResourceReference
* ResourceAction (extends ResourceReference by adding an action field)
* ResourceReferenceSerializer
* ResourceReferenceResolver
* ResourceExecutor(ResourceReference). Hint = <executor type>/<resource type>/<resource action>
Example: View "entity:view:wiki:space.page@my.png" in XHTML
Algorithm:
- lookup ResourceExecutor (hint = "xhtml/entity/view")
- cast ref = ResourceReference.getReference() to EntityReference
- if ref.type == ATTACHMENT
- get attachment URL
=> <img src="..../my.png"/>
Example: Generate URL for "entity:view:wiki:space.page@my.png"
Algorithm:
- lookup ResourceExecutor (hint = "url/entity/view")
- cast ref = ResourceReference.getReference() to EntityReference
=> http://wiki/xwiki/bin/view/space/page/my.png
OR simply:
ResourceExecutor(ResourceAction). Hint = <executor type>
ex: "xhtml", "url", etc.
And it's up to the executor to have sub components for the various actions, resource types....
Conclusion
===========
The API is not completely finished and I'd need to explore it (ie start implementing it) to refine it.
Right now I'd just like to discuss whether you see the idea as interesting and whether I should start spending some time working on it.
I'll post refinements as I progress.
Thanks
-Vincent
Hi devs,
Adding the notion of Workspaces is a feature required by the Wiki3.0 (
http://wiki30.xwikisas.com ) research project that XWiki is currently
involved in.
To read the proposal and several use cases, please see
http://dev.xwiki.org/xwiki/bin/view/Design/Workspaces
Your feedback is appreciated.
Thanks,
Eduard Moraru
Hi developers,
I've setup and worked on a couple of wiki farms recently, and my feedback is
that the PR issue has become for me a major PITA.
It's worst than before, because we've introduced a lot of pages that
requires it : annotations style and script, plus the wiki macros for
activity, tag cloud, space, etc. (OK, it's not really PR, it's edit right of
the last person who did edit it, but it's the same issue mostly : you need
to have it saved by someone with sufficient rights).
Importing not as back-up (meaning all pages imported from the XAR are saved
by the user doing the import) is not sufficient answer, for several reason :
* User might not have programming rights
* When user has programming rights, it's a BAD practice in terms of security
(it means every page of the wiki initially has the PR right OK)
* Wiki creation is also done by template wiki copy, which is not covered by
this
* This problem is not just an import/creation problem, we need generally a
way to know which pages require PR, and which are missing this PR (users can
be deleted, their rights can change, etc.).
OK, that looks like sufficient complaining :)
Here what I propose, tell me what you think :
1. We define a XWiki class, like XWiki.RequiredRightClass, with a field that
describe the required right the user saving the document must have for it to
behave properly (for example it will be "edit" for wiki macros with a "wiki"
scope, and "programming" for pages that uses privileged APIs, or JSR
scripts, or always use SSX, etc.)
2. We make a simple UI (for example in the administration section of the
admin app) that list all of them, and their current status. Plus a button to
fix the status if there is something to fix (a missing PR for example) and
if the user seeing the page has the required rights of course.
That's what I propose for now.
In the future, we could imagine that :
3. Programming right can only be granted on a page that requires
it explicitly. This would be a non-backward compatible change.
Let me know what you think.
If we agree I volunteer to implement this in 3.0 M2.
Jerome.
Hi devs,
We're accepting new wikis on myxwiki.org as requests come in but we already have 110 wikis created on it.
When do we know we shouldn't accept new wiki creation on that JVM because it's degrading performances too much?
Do we have tool to monitor wiki activity and publish on a page which wikis are using the most resources?
Do we have tools to display response time stats and see how they evolve over time?
Thanks
-Vincent
Hello,
Where can I find code responsible for loading/unloading jars?
It looks like
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-extension/ branch
with code for extension manager (where I planned to start the search from)
has moved somewhere. Thus asking for a hint.
A little background. Reason for request is that I'll probably try
borrowing this component for use in our project . The library we were using
( http://jcloader.sourceforge.net/ ) is LGPL v3 which is not applicable for
our business model anymore (LGPLs of earlier versions still apply) thus
looking for something similar.
Regards,
Roman
--
View this message in context: http://xwiki.475771.n2.nabble.com/Code-responsible-for-loading-unloading-ja…
Sent from the XWiki- Dev mailing list archive at Nabble.com.