fyi.... At some point we'll need to migrate.
Some things I've noticed from the release notes:
- their new syntax #[[...]]# is going to be fun for us... :(
- the velocimacro.context.localscope replacement is important for us
-Vincent
Begin forwarded message:
> From: Nathan Bubna <nbubna(a)apache.org>
> Date: December 1, 2010 7:46:29 AM GMT+01:00
> To: announce(a)apache.org, Velocity Developers List <dev(a)velocity.apache.org>, Velocity Users List <user(a)velocity.apache.org>, general <general(a)velocity.apache.org>
> Subject: [ANNOUNCE] Apache Velocity Engine 1.7
>
> The Apache Velocity Team announces the immediate availability of the
> of Apache Velocity Engine 1.7. This release is fully compatible with
> the previous release and includes significant improvements in
> performance, stability and features.
>
> Apache Velocity is well-known in the Java field as a lightweight,
> easy-to-use templating library for creating dynamic web sites and
> performing other text-generation tasks.
>
> Much work in this release has gone to making Velocity more
> user-friendly, adding some long-desired features and improving many
> others. Apart from this, numerous bugs were fixed (both common and
> obscure), deprecation warnings were added to push people toward the
> eventual 2.0 version, and performance continues to be improved. Some
> details are listed below:
>
> * There are four new syntax features:
> - #[[ This is a literal text block. It is not parsed, but directly
> fed into the output. ]]#
> - #@yourMacro() can now have body content. Just remember to add the
> @ when calling it with a body! #end
> - You can use brackets to get and set values in lists (and arrays).
> e.g. #set( $foo[2] = $bar[$i] )
> - Quotes, both single and double, may be escaped in string literals
> via doubling. e.g. #set( $foo = "Like ""this""!" )
>
> * There are five notable deprecations:
> - $velocityCount should be changed to $foreach.index (0-base) or
> $foreach.count (1-base)
> - $velocityHasNext should be changed to $foreach.hasNext,
> $foreach.last or $foreach.first
> - The #literal directive has been replaced by #[[ the much superior
> textblock ]]#
> - The velocimacro.context.localscope setting is being phased out;
> please get/set local #macro references as members of the optional,
> context-aware and self-documenting $macro "namespace" object. (e.g.
> #set( $macro.foo = 'bar' ) and $macro.foo). Enable this by setting
> macro.provide.scope.control=true in your properties.
> - The directive.evaluate.context.class setting is being phased out;
> please get/set local #evaluate references as members of the $evaluate
> "namespace" object. Enable this by setting
> evaluate.provide.scope.control=true in your properties.
>
> * The are three important changes:
> - The #stop directive now stops rendering instead of parsing, making
> it much more useful.
> - The #break directive can now be used in any scope, not just in a
> nested #foreach. It will terminate the nearest content "block",
> whether a directive, a macro body, or an entire template.
> - All templates, standard block (aka "content") directives, macros,
> macro bodies, #evaluate content and #define blocks can be easily
> configured to have an automatically-provided, context-aware and
> self-documenting namespace reference in which you can safely and
> securely #set and get any "local" references to keep them out of the
> global context.
>
> See the change log for a more complete explanation of any and all of
> these, or ask us about them at user(a)velocity.apache.org.
>
> Documentation Velocity 1.7 can be found here:
> http://velocity.apache.org/engine/releases/velocity-1.7/
>
> The change log is here:
> http://velocity.apache.org/engine/releases/velocity-1.7/changes-report.html
>
> Apache Velocity 1.7 can be downloaded here:
> http://velocity.apache.org/download.cgi
>
> For the Apache Velocity Team
> Nathan Bubna
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: announce-unsubscribe(a)apache.org
> For additional commands, e-mail: announce-help(a)apache.org
>
>
Hi!
Just a one line to congratulate the whole XWiki team and community for
getting XWiki farm running in the 2.6 XE/XEM featuring colibri skin. It
looks great!
Thanks for your work!
Ricardo
--
Ricardo RodrÃguez
CTO
eBioTIC.
Life Sciences, Data Modeling and Information Management Systems
Hi,
I think we should provide default template providers in default XE. This thread is about deciding which ones to have by default.
Candidates:
==========
1- Wiki Macro
2- Blog Post
3- Scheduler Job
4- Class (same result as creating a class from the class wizard)
5- Color Theme
6- Panel
7- Skin
For some of these we have home pages to create them (For example: Blog, Scheduler, Class, Color Theme, Panel) so we need to decide if it's ok to provide 2 locations from where to create them.
In addition some of the candidates above are technical things and they shouldn't be displayed to simple users IMO: Wiki Macro, Scheduler Job, Class, Color Theme, Panel, Skin.
Thus I'd also like to discuss having a mechanism for a Template Provider to say to whom it's addressed. Could be done by adding an "Audience" field to the Template Provider class.
WDYT?
Thanks
-Vincent
Hi,
I've recently had the need to modify the list of blacklisted spaces on one
of my wikis. I had to override a .vm file to do that. I was reminded of this
issue while reading Vincent's email about default template providers and the
need to hide technical items. Hiding some specific spaces is a frequent use
case, for instance I often create a "Code" space to hold all my code files
and I'd like to hide it from the main dashboard but there's no easy way to
do that right now.
It would be great if instead I could simply edit a field in the
"Programming" section of the administration to define which spaces should be
blacklisted.
Here's my +1 for that.
WDYT?
Guillaume
Hi devs,
I'd like to add a new administration section for the WYSIWYG editor. For
this I'll create a new page:
XWiki.WysiwygEditorConfig (storing the WYSIWYG editor configuration
class/object and the XWiki.ConfigurableClass objects)
Is this fine with you? I don't think a separate application is needed yet.
The WYSIWYG editor configuration will contain there sections/properties:
General settings
----------------
Display the WYSIWYG/Source tabs [Yes/No]
The editor tab selected initially [WYSIWYG/Source]
The list of enabled plugins [submit line separator ...]
The top menu items [link image table macro import]
The list of tool bar items [bold italic underline ...]
Link settings
-------------
Limit attachment selection to the edited page [Yes/No]
Image settings
--------------
Allow insertion of external images [Yes/No]
Limit image selection to the edited page [Yes/No]
Color settings
--------------
The colors available in the color picker
[#000000,#444444,#666666,#999999,#CCCCCC ...]
The number of colors to display per row in the color picker [8]
Font settings
-------------
The list of available font names [andale mono, arial, arial black, ...]
The list of available font sizes [8pt, 10pt, 12pt, ...]
Style settings
--------------
The list of predefined styles []
WDYT?
Thanks,
Marius
On Tue, Nov 30, 2010 at 16:00, jvdrean <platform-notifications(a)xwiki.org> wrote:
> Author: jvdrean
> Date: 2010-11-30 16:00:36 +0100 (Tue, 30 Nov 2010)
> New Revision: 33193
>
> Modified:
> Â platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/ImportAction.java
> Â platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/importer/import.js
> Log:
> XWIKI-5724 : On import document author is not the current user
>
> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/ImportAction.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/ImportAction.java   2010-11-30 14:43:36 UTC (rev 33192)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/ImportAction.java   2010-11-30 15:00:36 UTC (rev 33193)
> @@ -133,6 +133,8 @@
> Â Â Â Â Â Â Â Â Â Â // Set the backup pack option
> Â Â Â Â Â Â Â Â Â Â if (StringUtils.equals(request.getParameter("importAsBackup"), "true")) {
> Â Â Â Â Â Â Â Â Â Â Â Â importer.setBackupPack(true);
> + Â Â Â Â Â Â Â Â Â Â } else {
> + Â Â Â Â Â Â Â Â Â Â Â Â importer.setBackupPack(false);
> Â Â Â Â Â Â Â Â Â Â }
WDYT about:
importer.setBackupPack(Boolean.valueOf(request.getParameter("importAsBackup")));
instead ?
> Â Â Â Â Â Â Â Â Â Â // Import files
> Â Â Â Â Â Â Â Â Â Â importer.install();
>
> Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/importer/import.js
> ===================================================================
> --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/importer/import.js  2010-11-30 14:43:36 UTC (rev 33192)
> +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/importer/import.js  2010-11-30 15:00:36 UTC (rev 33193)
> @@ -298,6 +298,7 @@
>
> Â Â Â Â Â Â parameters["historyStrategy"] = $('packageDescription').down("input[type=radio][value='add']").checked ? "add" :
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ($('packageDescription').down("input[type=radio][value='replace']").checked ? "replace" : "reset");
> + Â Â Â Â Â Â parameters["importAsBackup"] = $('packageDescription').down("input[type=checkbox][name='importAsBackup']").checked ? "true" : "false";
> Â Â Â Â Â Â parameters["ajax"] = "1";
>
> Â Â Â Â Â Â var pages = [];
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications
>
--
Thomas Mortagne
Hi devs,
I'd like to introduce a new feature in the WYSIWYG editor in XE 2.7: the
ability to apply predefined custom styles to a text selection. Using
this instead of the other text formatting features (e.g. font name, font
size, text color etc.) can help improve the consistency between wiki pages.
Wiki administrators will be able to define a list of custom styles (CSS
class names) which will be listed in a select box on the WYSIWYG tool
bar. These styles should have meaningful names, e.g. "important",
"comment", "todo" etc..
Considering that this feature is independent and will be disabled by
default (i.e. we don't provide predefined styles in the standard XE
distribution) I think it's save to introduce it in 2.7. Let me know if
you are against it.
Thanks,
Marius