Hi,
I would like to retrieve the number of document that is viewable by the current user (Meaning it has the access to the document).
How can i modified the following codes to achieve that feature?
#set($query="select count(doc) from XWikiDocument doc")
#set($resultsCount = $xwiki.search($query).get(0))
Thanks in adv,
Colin
Get your preferred Email name!
Now you can @ymail.com and @rocketmail.com
http://mail.promotions.yahoo.com/newdomains/sg/
jvelociter (SVN) wrote:
> Author: jvelociter
> Date: 2009-04-22 02:16:46 +0200 (Wed, 22 Apr 2009)
> New Revision: 18927
>
> Modified:
> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js
> Log:
> XWIKI-3175 Clean the javascript global object from method and properties that should not be exposed
>
> I think we can safely removed this XWikiAjax method definitely.
Shouldn't it be placed in the deprecated file instead?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hello wikiers,
Congratulation to all of you selected people for working on xwiki projects
and I wish you a nice summer coding and playing with xwiki API !!!
Regards,
Keerthan Muthurasa
Hi Devs,
First of all, sorry about the long email subject :)
Our style filter is working quite nicely and users so far like it very much
:). Still, word documents sometimes contain really really (I mean really)
huge images embedded in them. In such cases since our style filter rips off
height & width attributes of <img> tags, images run way off the page
boundaries (looks very ugly).
Following are the only attributes currently allowed with our style filter:
a --> href, name
img --> alt, src
td --> colspan, rowspan
I think we have to add height & width attributes into this set (under img
tag) because heights & widths are not actually styling attributes (IMO).
Note: We are discussing about cleaning OO generated html content that comes
from a word document, not about general html cleaning.
WDYT?
Thanks.
- Asiri
Hi Guys,
I've refactored a little
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices to
introduce practices for Front-End development.
Right now it's only a set of practices for JavaScript development (rules
about external libraries, namespacing and backward
compatibility/deprecation), but I'd like that in the future we add
practices for Design (UI consistency, UX guidelines, etc.) and CSS
development.
Since the rules I've added for JS have not all been voted (none except
the deprecation strategy has been voted in fact), they are of course
open to discussion.
Tell me what you think,
Regards,
Jerome.
Hi,
sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2009-04-20 22:25:52 +0200 (Mon, 20 Apr 2009)
> New Revision: 18869
>
> Added:
> platform/web/trunk/standard/src/main/webapp/resources/icons/xwiki/
> platform/web/trunk/standard/src/main/webapp/resources/icons/xwiki/ajax-loader-large.gif
> platform/web/trunk/standard/src/main/webapp/resources/icons/xwiki/ajax-loader-white.gif
> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/
> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js
> Modified:
> platform/web/trunk/standard/src/main/webapp/templates/edit.vm
> platform/web/trunk/standard/src/main/webapp/templates/editactions.vm
> platform/web/trunk/standard/src/main/webapp/templates/inline.vm
> platform/web/trunk/standard/src/main/webapp/templates/macros.vm
> platform/web/trunk/standard/src/main/webapp/templates/preview.vm
> platform/web/trunk/standard/src/main/webapp/templates/previewactions.vm
> Log:
> XWIKI-3654: Improve editor and preview buttons
> XWIKI-2597: Hitting 'Back to edit' after previewing an in-line form does not return to inline editing
> XWIKI-3653: Edit comment and Minor edit settings lost when going to the preview and back to edit
> Done.
>
> [snip]
>
> Added: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js
> ===================================================================
> --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js (rev 0)
> +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js 2009-04-20 20:25:52 UTC (rev 18869)
> @@ -0,0 +1,218 @@
> +// ======================================
> +// Form buttons: shortcuts, AJAX improvements and form validation
> +// To be completed.
> +if (typeof(XWiki) == 'undefined') {
> + XWiki = new Object();
> +}
> +if (typeof(XWiki.actionButtons) == 'undefined') {
> + XWiki.actionButtons = new Object();
> +}
> +
> +XWiki.actionButtons.EditActions = Class.create({
Why do you make this a class and not an object ? It looks like it will
never be instanciated more than once
> + initialize : function() {
> + this.addListeners();
> + this.addShortcuts();
> + this.saveAndContinueListener = new XWiki.actionButtons.EditActions.AjaxSaveAndContinue(this);
> + },
> [snip]
> + onCancel : function(evt) {
> + evt.stop();
> + var location = evt.element().form.action;
> + if (location.indexOf('?' == -1)) {
> + location += '?';
> + }
> + window.location = location + 'action_cancel=true';
> + },
> + onPreview : function(evt) {
> + if (!this.validateForm(evt.element().form)) {
> + evt.stop();
> + }
> + },
> + onSaveAndView : function(evt) {
> + if (!this.validateForm(evt.element().form)) {
> + evt.stop();
> + }
> + }
> +});
Maybe we could fire custom events here for code that want to listen to
cancel/preview/save clicks. I faced the case several times, and ended up
using some wicked CSS selectors to find the buttons to observe.
We could do something like :
onSaveAndView : function(evt) {
if (!this.validateForm(evt.element().form)) {
evt.stop();
}
else {
document.fire("xwiki:actions:save:before");
}
}
Jerome.
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications
Hello guys,
I'm back after some months away...
I wanted to create my small website looking like a website (and not like a
blog) where I could express myself (even if I don't think it is very
interesting ) and where I could test some technologies at the same time...
my live public laboratory...
I have been working with some CMS for some time now and also with wikis...
Beyond the common discussions about the differences between CMS and Wiki I
can find everywhere, I still think both approaches are compatible and
complementary...
Personnally, I prefer writing, formatting with Wiki syntaxes but I also like
skinning and authoring/publishing mechanisms in CMS...
I have decided to make an experimentation by designing my website using
Wiki+CMS...
I have chosen:
- Magnolia CMS since it's designed around a Java lightweight architecture,
fully implementing a JCR storage (this was one of my interests also), it
provides publishing workflow between a private and public instances and it
provides a nice skinning and authoring mechanism... There are lots of
defaults and poor docs in it but this is not the question here.
- XWiki for the wiki because as George says:"What else????"... I also
decided to use only XWiki/2.0 syntax to test it deeply...
I wanted:
- to use the CMS as the content aggregator and XWiki as one content provider
- to use XWiki remotely and enable content retrieval from several XWikis for
example
- to integrate XWiki pages as paragraphs into a magnolia page containing
other contents
- to allow remote XWiki edition using a "simplified" XWiki editor
So I have developped:
- a Magnolia module which manages the creation/edition/insertion of XWiki
paragraphs into Magnolia. The XWiki pages are retrieved remotely from one
XWiki server using the XMLRPC API for the time being...
- a "light" XWiki editor based on velocity templates from the basic XWiki
skin.
You can see the resulting website in this site:
http://www.mandubian.org
It's a draft site so please don't look too much at the quantity of content
(and the quality also ;) )
I will build progressively the website, deliver, document and improve the
XWiki/Magnolia module also and bring new ideas also...
This is a private server so don't be surprised when it is not very quick!
regards
Pascal Voitot