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
Hi Sergiu,
sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2009-04-19 21:40:15 +0200 (Sun, 19 Apr 2009)
> New Revision: 18827
>
> Added:
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/boolean.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/calendar.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/database.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/groups.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/move.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/number.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/password.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/propertyType-Generic.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/rights.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/staticlist.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/string.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/textarea.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/tree.png
> platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/users.png
> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/dataeditors/
> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/dataeditors/dataeditors.css
> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/dataeditors/dataeditors.js
> Modified:
> platform/web/trunk/standard/src/main/webapp/templates/editclass.vm
> platform/web/trunk/standard/src/main/webapp/templates/editobject.vm
> platform/web/trunk/standard/src/main/webapp/templates/editpanelsvars.vm
> Log:
> XWIKI-3635: Improve the object and class editors
> Done. L10N will be done afterwards.
>
>
[snip]
> Property changes on: platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/rights.png
> ___________________________________________________________________
> Name: svn:mime-type
> + image/png
>
>
This image is not very comprehensive. I had to look twice before getting
it is key ring.
[snip]
> +XWiki.XPropertyOrdering = Class.create({
Shouldn't this be namespaced under the XWiki namespace ?
For example "XWiki.dataeditor.XPropertyOrdering"
If we do not make submodules in the XWiki objects, we'll make the same
mistake we did with the window object, and we will end up with a large
collection of properties and functions that have nothing to do one with
each other.
I'd rather keep the XWiki object for both holding modules and
functions/classes/properties that have sense in all XWiki pages, not
just in one module.
Jerome.
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications
jvelociter (SVN) wrote:
> Author: jvelociter
> Date: 2009-04-16 20:03:35 +0200 (Thu, 16 Apr 2009)
> New Revision: 18760
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties
> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources_fr.properties
> platform/xwiki-applications/trunk/tag/src/main/resources/XWiki/TagCloud.xml
> Log:
> XE-430 In space dashboard, display tag cloud with tags of the space
>
>
> Modified: platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties 2009-04-16 17:21:20 UTC (rev 18759)
> +++ platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties 2009-04-16 18:03:35 UTC (rev 18760)
> @@ -1117,6 +1117,7 @@
> # Tag application
> xe.tag.tags=Tags
> xe.tag.notags=No document has been tagged yet. Documents can be tagged from the information section (footer) or from the Document information panel available in edit mode. For more information on tagging please refer to the <a href="http://www.xwiki.org/xwiki/bin/view/UserGuide/">User Guide</a>.
> +xe.tag.notagsforspace=No document has been tagged yet in space *{0}*. Documents can be tagged from the information section (footer) or from the Document information panel available in edit mode. For more information on tagging please refer to the <a href="http://www.xwiki.org/xwiki/bin/view/UserGuide/">User Guide</a>.
I think we should rethink how/if to use wiki markup in localization
resources. This would fail if used in a document with the 2.0 syntax,
since the bold markup was changed.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
* Thomas and I would like to split the current begin/endDocument()
events by adding begin/endGroup(). We're currently reusing the same
event for group usage (with the (((...))) syntax).
* This will allow us to write things such as (%...%)(((....))) in
order to add parameters for a group of standalone blocks
* We also propose to remove the (%...%)...(%%) notation in favor of
(%..%)(((...))) notation
* (%..%) will always be applied only to the next element, even for
inline content.
* Add support for (%...%){{macro/}}
Here's my +1
Thanks
-Vincent
Thanks!
It works like a charm ;)
You are looking for something like:
#if($xwiki.getUser("XWiki.Admin").isUserInGroup("XWiki.XWikiAllGroup"))
...
#end
Check the API of your XWiki (http://platform.xwiki.org/xwiki/bin/download/DevGuide/API/xwiki-core-1.8.1-…), please.
Here a snippet where the prefix "XWiki." is handled in Velocity. Only the user login name and group name has to be entered.
Have fun,
Rudi
#if(($request.action) && ($request.action == 'CheckGroupMembership'))
#set($group = "XWiki.${request.group}")
#set($user = "XWiki.${request.user}")
#if($xwiki.getUser($user).isUserInGroup($group))
User $user IS in group $group
#else
User $user IS NOT in group $group
#end
#end
1 Check Group Membership
<form action="$doc.getURL("view")" method="post">
<input type="hidden" name="action" value="null" />
<table>
<tr>
<td>Group:</td>
<td><input type="text" name="group" value="$!request.group" size="60" /><td>
</tr>
<tr>
<td>User:</td>
<td><input type="text" name="user" value="$!request.user" size="60" /></td>
</tr>
</table>
<input type="submit" value="Check Group Membership" onclick="document.getElementById('bequiet').style.visibility='visible';this.form.action.value='CheckGroupMembership'" />
<!-- <input type="reset" value="Cancel" /> -->
<div id="bequiet" style="visibility:hidden">
<h1>busy...</h1>
</div>
</form>
Hi
I`m trying to figure a way to check if a user is a member of one group.
I`m looking for something like:
a) retrieve the groups membership of an user in velocity
or
b) check if a user is a member of a specify group.
Thanks in advance
Regards,
Bruno
--
View this message in context: http://n2.nabble.com/Group-Members-in-Velocity-tp2641137p2652257.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white
spaces (WS) in HTML and Velocity Macro.
If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the
current problem is that we cannot indent scripts since WS and NL are
meaningful.
I'd like to reiterate the proposal that was sent but not enough people
voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes:
- strip NL/WS between elements (elements that don't accept CDATA)
- strip leading/trailing NL/WS for element content before passing them
to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able
to have a line break with the new line starting with spaces without
escaping the leading space with ~(space).
Note also that this means we will not be able to add extra new lines
to format the text nicely (since that would add new paragraphs) or
split a single line into several lines for extra readability. This is
the case today with the old syntax and it's a pain not to be able to
aerate the text with empty lines.
Ex:
some text
~ next line #if (...) this goes on the same line #something(...)
#end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same
line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between
"words" (same as HTML).
The user would use something like $nl and $sp to explicitely enter new
lines and spaces.
The advantage is that you control completely the formatting (no magic
anymore) at the cost of a little extra work (adding the $nl where
required).
Basically this means the same pros/cons as when you work with HTML
where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl
$sp next line
#if (...)
this goes on the same line
#something(...) <-- this is also on the same line
#end
$nl $nl
This a new paragraph
Note: I've aerated the text by putting extra new lines around the
velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced"
line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more
than 1 leave them.
Ex:
some text\\
~ next line
#if (...)
this goes on the same line
#something(...) <-- this is also on the same line
#end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too
big a change for our users or not. If not 2) then 3).
Thanks
-Vincent