Hi,
Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274
Basically if you do $xwiki.getDocument("someDoc").getRenderedContent()
it'll get executed in the context of the current doc which I believe
is wrong especially since other signatures of getRenderedContent()
execute in the target document's context.
I have fixed this locally but found that admin.vm for example is
assuming that getRenderedContent() will get executed in the context of
the calling doc (i.e. XWiki.Import when doing an import for example).
FYI the chain flow is admin.vm -- getRenderedContent() -->
XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which
requires the current doc to be XWiki.Import (to get/put attachments
from/to it).
I can fix this easily using a new getRenderedContent signature I've
introduced.
However I'm wondering if we have other places that incorrectly use
getRenderedContent() and assume it won't be rendered in the context of
the target document.
Is this change too dangerous to make? If not know, we'll need to it
quickly (2.1M1?) since it's an important bug IMO.
WDYT?
Thanks
-Vincent
Could be useful:
http://ocpsoft.com/prettytime/
Idea of usage: For ex we could use that to show the last modified
document dates for dates in the past week (for ex):
"Document created 2 days ago"
It's in the maven central repo and it's under LGPL
-Vincent
Hi Everyone!
I have read this document "Writing GWT applications in XWiki" (
http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingGWTApplicationsInXWiki)
And I know how to develop GWT module for xwiki now. I also have read the
document "WYSIWYG Editor Module" (
http://code.xwiki.org/xwiki/bin/view/Modules/WysiwygEditorModule). I
followed the instruction which tried to integrate the WYSIWYG editor(GWT
application) in wiki pages, and I put the following code in my wiki editor:
"{{html}}
<script type="text/javascript" src="XWikiWysiwyg.js"> alert('WYSIWYG code is
loaded!'); </script> <textarea id="demo"></textarea> <script
type="text/javascript"> Wysiwyg.onModuleLoad(function() { new
WysiwygEditor({hookId:'demo'}); alert('WYSIWYG code is loaded!'); });
Wysiwyg.onModuleLoad(function() { editor = new WysiwygEditor({hookId:
'demo'}); }); }); </script> {{/html}}"
After saved, it only display a blank text area without any sign of WYSIWYG
editor, also there is no alart 'WYSIWYG code is loaded!' popup. Can you help
me figure it out what is wrong with it?
I am planing to develop a tree view using GWT to display Design Rationale
Element. Could you give me some ideas of after my development, how can I
embeded the GWT application into Xwiki pages and interact with the GWT
application?
Thank you very much!
Leon
Hi,
Part I
=====
I've started implementing a Ditaa Macro over the weekend (http://ditaa.sourceforge.net/
) but we need an Action to return the Ditaa-generated image file.
For the chart macro we're using the charting action but I think we can
make this generic and instead introduce a tmp (or temp or tmpresource
or ...) action instead that would return any resource located in the
xwiki temporary directory.
For ex:
/xwiki/bin/tmp/SomeResource
would return SomeResource found in
container.getApplicationContext().getTemporaryDirectory().
Part II
=====
The only thing to be careful about is to not be able to read what's
for another user and for which you don't have access to see it. For
example an image generated by the chart macro for a page for which the
user doesn't have view rights. This can be partially solved by
ensuring that file names include a generated token. However the pb is
that this token cannot be unique since, for ex, generated image need
to be shared to anyone having the rights to view a page.
<brainstomring mode>
A solution I see would be to include the "rights" to check + the full
page name in the URL, in addition to the resource. For example:
/xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
A more generic solution would be to add a notion of Check Handler,
i.e. code that would perform the check. For example in the previous
solution it's not possible to check for 2 permissions, nor any complex
scheme. This would mean something like:
/xwiki/bin/tmp/<check handler name>/<resource name>?<check params>
Ex: /xwiki/bin/tmp/simple/SomeResource?
checkPermission="view"&checkDocument="wiki:Space.Page"
Implementation: A component with a role hint of "simple" would be
looked-up and the check logic delegated to it.
However someone could use a some check for a resource that wasn't
meant to be used for that resource.
Thus the check and its params should probably instead be included in
the resource name with some algorithm instead. Thus the solution maybe
to have a high level API to create a resource name and that API would
take a Check Handler hint + some arbitrary params and that API would
generate a resource name with these added. For ex something like::
"SomeResource-simple-view-wiki:Space.Page" (or any other format).
Another solution would be to follow a completely different direction
and for example to introduce a new XDOM representation for a TMP-
image, i.e. in addition to URLImage and DocumentImage, to add a
TemporaryImage implementation.
</brainstomring mode>
WDYT about these 2 ideas and especially about Part I since I would
need that sooner rather than later to implement the Ditaa macro, and
Part II is already a problem today.
Thanks
-Vincent
Hi devs,
We need to support some way internationalization of everything in the
rendering that appear in the UI, for now it's mainly related to
macros.
What I propose is to introduce the rule that any displayable String
returned by the API (MacroDescriptor#getName,
ParameterDescriptor#getDescription, etc.) could be a l10n key. Then
the API user call the l10n component to get the final String.
pros:
- no need to touch the current API
- it avoid having complex API to support l10n specifics and makes
pretty much everything depends on l10n component. It's easier for
macro author to write a quick macro with some description without
having to create l10n resource and call the l10n component just for
english for example.
- the displayer can control how to get actual translations the way it wants
- we need something like that for wiki macros anyway: XWiki does not
support translations of objects yet (and for long I guess since the
issue is at database level) and it would be a pain to have to copy the
content of the macro by language since most of the time the script of
the macro would not be related to the language
cons:
- it's more work for the API user to filter the String with the l10n
component to get the actual final String
One detail I'm not sure of is if we introduce some syntax to
explicitly indicate it's a l10n key or if we just always give the
String to the l10n component which will return it as it is if it can't
find any matching key.
Having an explicit way to indicate a String is a key would be better
to track l10n keys bugs but introduce a syntax is always more complex
(what chars to choose, how to escape, etc...).
WDYT ?
Thanks,
--
Thomas Mortagne
Hi there,
I'd like to start a overhaul of the xwiki.org home page + a first
level navigation overhaul.
Today:
* Home page = list the different products
* First level nav = the ecosystem panel
Problems:
* We now have a single product: XE and all the others are actually
modules that plugin into the main products. Hence we shouldn't focus
on other products so much IMO.
* I'd like to view xwiki.org as a forge of projects. Today our top
level projects are the ones listed here: http://svn.xwiki.org/svnroot/xwiki/
* The main page should be more dynamic and show some news and activity
instead of being static
* People are confused by the top level navigation vs the second level
one because they both use panels and it's not easy to differentiate them
Proposal:
* Use a horizontal top level navigation with the following items (from
left to right):
- Overview or Home (the main page)
- Platform
- Projects (when clicked will list all top level projects) - We could
have the list of subproject available as submenu items too (as it's
done on http://jboss.org/)
- Support (when clicked will explain the various ways to get support
including mailing list/forum, irc/jabber, FAQ & listing companies
offering commercial support)
- Contribute or Community (when clicked we'll get dev.xwiki.org)
- Playground
This means that the panels on the right will become the second level
navigation and the content will depend completely on where you are on
the site.
* Have some facilities links in the header on the right:
- News
- Downloads (as a visible button maybe)
* On the home page:
- Have a nice diagram of the xwiki platform that shows how XE, XE
modules are positioned on the platform so that people understand right
away that xwiki is a collaborative web dev platform
- Have a Highlight box with XE so that users looking for a full-
fledged wiki can quickly see it and click on it + maybe one featured
screenshot of an entry from the References page that would be
different every time the page is refreshed (this could encourage
people to add references + provide a link to the references directly)
- Have a Featured project box and list 3-4 featured projects (XE, XEM,
XEclipse, XOffice for ex to start with)
- Have some news:
-- latest 5 blog post titles
-- latest 5 code zone additions (all snippet, plugins, macro, apps,
etc included)
-- latest 5 mailing list threads subjects (with links to our nabble
forum)
We could not have any second level navigation for the home page in
order to have more space for displaying the elements above.
WDYT?
If/when we're ok in term of content maybe Cati (or anyone interested)
could provide some mockups of what it could look like.
Thanks
-Vincent
PS: Let's not get bogged down with details at this point. I think
what's important is to make progress and refine later on. What's
important is that we agree on the broad lines at this stage.
Hi everyone (devs and users),
While we have a clear governance for write access to our source
repository (http://dev.xwiki.org), we're missing a clear governance
for xwiki.org. The idea is to address mainly the following 2 questions:
1) who "owns" it and thus "controls" (or rather provides direction
for) its content
2) can it be used for business advertising (support, paid packages,
consulting services)
Bit of History about XWiki SAS
========================
- XWiki SAS (http://xwiki.com) is the company founded by Ludovic
Dubost the creator of XWiki (I'm the CTO of XWiki SAS in addition to
being a committer here).
- Most of the active contributors are also employed and paid by XWiki
SAS to develop the XWiki software. Today that's
-- 12.5 committers (developers)
-- 1 open source product manager (see http://markmail.org/thread/ggaaw4u6yyci4oan
for its definition)
-- 1 designer
-- 1 tester/technical writer
- XWiki SAS sells services around the open source software, see http://www.xwiki.com/xwiki/bin/view/Services/
- XWiki SAS truly believes and understands open source, see http://www.xwiki.com/xwiki/bin/view/About/Values
-- I also wrote a blog post on this some time back: http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiSASAndOpenSource
- XWiki SAS has promised "not to do evil" ;), see its manifesto at http://www.xwiki.com/xwiki/bin/view/About/Manifesto
- XWiki SAS is paying for the servers and maintenance of xwiki.org,
myxwiki.org, the maven repo, the svn repo, the hudson build serversn
the free JUG farm, and more
Issue at hand
===========
XWiki SAS would like to generate more revenue to be able to increase
the development pace of the XWiki software. We'd like to fund even
more the development of XWiki, so that it becomes an even better
product. We've asked you what you'd like to see in the future in XWiki
and you've answered on this survey result:
http://www.xwiki.org/xwiki/bin/view/Blog/Features+Survey+Results
We'd like to implement those features as fast as possible.
For this we need to ensure that users interested in commercial
services find easily the way to http://xwiki.com, even when they
arrive on xwiki.org.
This is true for XWiki SAS's services but also for any company willing
to offer services around the XWiki open source project. There's no
magic. Developers need to be paid when they work full time on some
project. We need a commercial ecosystem around XWiki for it to
progress as quickly as its competitors (the collaboration market). We
need to allow for commercial companies the ability to generate revenue
from their work on the XWiki open source project. However we also want
to continue ensuring that all the XWiki development is done in open
source, under a LGPL license.
Governance Proposal
=================
1) xwiki.org is controlled by the XWiki committers. This means that
important changes brought to it should be discussed/vote on the list,
using the same practices as for code commits
2) xwiki.org stays open in edit mode to all external contributors (and
XWiki committers continue to monitor it to remove spam, etc)
3) we agree to start with 3 zones where companies can advertise their
commercial offers on top of the XWiki open source product:
-- On the download page (for business packages, subscriptions, hosting)
-- On the support page (for services: support, consulting)
-- (still to be defined) Possibly on a "Products" tab in the new
horizontal navigation. The idea would be to do as jboss.org is doing.
Projects are open source and community and Products are commercial
4) the company offerings are listed by their amount of contributions
to the XWiki open source project. The company that contributes most
(XWiki SAS today) gets the best spots (top of the list, bigger space)
5) Companies who want to be listed should provide some proof of their
contributions to the XWiki open source project
6) XWiki SAS gets some acknowledgment for paying for the xwiki.org
server/maintenance of it. Probably somewhere in the footer of the site
or on side panel somewhere
7) xwiki.org should always remain a site for the xwiki open source
community
Conclusion
=========
We want to stress that this proposal is not about XWiki SAS making a
commercial takeover of the xwiki.org site.
It's about recognizing that if the XWiki open source software
progresses quickly today, it's thanks to contributors but also for a
very large proportion to companies paying developers to work on it,
either directly (like XWiki SAS or other companies that have
developers contributing) or indirectly (by paying for example XWiki
SAS or other companies to work on specific features).
It's also about recognizing that XWiki SAS is happy to see other
companies willing to contribute to the progress of the XWiki open
source project and thus to provide a place for these companies to be
visible too.
I hope that all our contributors but also users of the XWiki Open
Source software will find this proposal acceptable and I welcome any
feedback on it.
Thanks
-Vincent Massol
Hat 1: XWiki SAS CTO
Hat 2: XWiki committer
Hi,
Since we introduce document footer informations view statistics are
store several time for the same user view of a page.
See http://jira.xwiki.org/jira/browse/XWIKI-4590
The issue is that theses tabs are loaded asynchronously in ajax and
make a call using view action.
Here are some solutions:
1/ introduce a new action "viewinternal", "service" or anything else
that would be a "view" action without UI and not taken into account by
statistics (that register for "view" action events)
2/ pretty much the same thing that 1/ but based on a URL parameter
3/ use an additional AJAX request similar to a google analytics call
to record statistics
As i said in jira I'm against 3/
2/ seems too big for a URL parameter to me and it makes statistics
depends on URL parameters where 1/ fix the issue without touching
anything in the statistics module
+1 for 1/
+0 for 2/
-1 for 3/
--
Thomas Mortagne
Hi,
This is following the proposal done here some time ago:
http://markmail.org/message/nnybto3mluvp2rov
Since we now have a generic Script notion we need to revisit it in
that light. Also we really need to implement it now since more and
more components are put in the velocity context (office importer,
syntax factory, etc) and we need to bring some order.
Here's a new generic proposal:
Short term
========
* The variable "services" is bound in the script context. For ex in
Velocity: $services
* The Services object (ScriptServiceManager) has a ScriptService
get(String serviceName) method which returns the service
* We use the namespace: services.<module name>.<method>. Each module
provides only one service entry point.
* ScriptService interface (empty interface) represents a service to
be bound in the context
* ScriptServiceManager.get() looks for all components of role
ScriptService and returns the component matching the the name as the
component hint.
Ex:
@Component("mymodule")
public class MyModuleScriptService implements ScriptService,
MyModuleBusinessInterface
{
public void myMethod() {}
}
In script:
{{velocity}}
$services.mymodule.myMethod
{{/velocity}}
Medium term
==========
* We handle @authorization(Authorization.PROGRAMMING) annotations to
check for access rights. To do this in ScriptServiceManager.get() we
use a Dynamic Proxy to implement MyModuleBusinessInterface (we
probably need a ScriptService.getInterface() method to make it
unambiguous). The Dynamic Proxy checks the annotation before proxying
to the real object.
WDYT?
Thanks
-Vincent
PS: This is to answer Sergiu's question about where is
getAvailableParserSyntaxes() from my other mail... ;) Answer: It would
be in RenderingScriptService.