Hi,
On Nov 12, 2010, at 2:19 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2010-11-12 02:19:09 +0100 (Fri, 12 Nov 2010)
> New Revision: 32741
>
> Modified:
> platform/web/trunk/standard/src/main/webapp/templates/menuview.vm
> Log:
> XE-750: Ability to send a link to a page by email
> Enabled the Share menu entry in non-Colibri skins
>
> Modified: platform/web/trunk/standard/src/main/webapp/templates/menuview.vm
> ===================================================================
> --- platform/web/trunk/standard/src/main/webapp/templates/menuview.vm 2010-11-12 01:14:31 UTC (rev 32740)
> +++ platform/web/trunk/standard/src/main/webapp/templates/menuview.vm 2010-11-12 01:19:09 UTC (rev 32741)
> @@ -136,6 +136,10 @@
> #if($canImport)
> #submenuitem($xwiki.getURL('XWiki.OfficeImporter', 'view') $msg.get('core.menu.create.pageFromOffice') 'tmActionImport')
> #end
> + #if (!$isGuest)
> + #submenuitem($doc.getURL('view', 'viewer=share') $msg.get('core.menu.share') 'tmActionShare', '')
> + $xwiki.jsx.use('XWiki.SharePage')
> + #end
Again the share this page should be an extension of the platform and thus the menu entry should be there only if the share application (or whatever app it's included with) is available.
WDYT?
Thanks
-Vincent
> #xwikitopmenuentryend()
> #if($canDelete && $keyboardShortcutsEnabled)
> <script type="text/javascript">
Hi,
I've worked on a livetable generator and livetable macro which allows to
generate the livetable configuration directly from the XWiki class.
http://code.xwiki.org/xwiki/bin/view/Macros/LiveTableMacro20Macro
It would be great if some devs could look at it, as it could be a good
candidate for inclusion in the platform as it would ease creating
livetables.
The current problematic parts are:
1/ A hack was made for translations as changes to the livetable macros
were necessary to allow to use the Pretty Names automatically instead of
translations
2/ It would be great to not even have to give the fields to use in the
LiveTable and use the information from the class where a checkbox could
be added for each field saying "include in default livetable"
This would be a good step towards full CRUD in XWiki. Now that we have
Templates, we could add a place in the Wiki where all documents can be
browser per class (using this livetable). We would just need a slightly
simpler Class Editor which hide the more difficult configurations from
classes.
The more important work is to support Class Sheets that don't need the
include macro to be used for documents that have an object of this
class, and a modification of the inline mode which could disappear.
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On Nov 11, 2010, at 8:25 PM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2010-11-11 20:25:14 +0100 (Thu, 11 Nov 2010)
> New Revision: 32725
>
> Added:
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/ExternalServletURLFactory.java
> Log:
> XWIKI-5681: New URLFactory that always generates external URLs
> Done.
>
> Added: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/ExternalServletURLFactory.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/ExternalServletURLFactory.java (rev 0)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/ExternalServletURLFactory.java 2010-11-11 19:25:14 UTC (rev 32725)
> @@ -0,0 +1,55 @@
> +/*
> + * See the NOTICE file distributed with this work for additional
> + * information regarding copyright ownership.
> + *
> + * This is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU Lesser General Public License as
> + * published by the Free Software Foundation; either version 2.1 of
> + * the License, or (at your option) any later version.
> + *
> + * This software is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this software; if not, write to the Free
> + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
> + *
> + */
> +package com.xpn.xwiki.web;
> +
> +import java.net.URL;
> +
> +import com.xpn.xwiki.XWikiContext;
> +
> +/**
> + * URL Factory which always prints the absolute (external) form of URLs.
> + *
> + * @version $Id$
Missing @since tags.
Thanks
-Vincent
[snip]
Hi XWiki Devs,
I've been performing some XWiki demos recently and it came to my attention
that when adding a comment to a page and then going back to the homepage, my
comments didn't show up in the recent activity section of the dashboard.
This is due to the fact that adding a comment is considered a minor event.
This behavior is still taking place in the most recent versions of XWiki
Enterprise (I tested a XE 2.7 snapshot this morning). I believe that
comments should be treated as major events, the same way that adding an
object or an annotation to a page is.
Therefore I propose making adding a comment a major event instead of a minor
one.
Here's my +1 for this.
Thanks,
Guillaume
Apology for cross posting.
Can someone point me to where in the XWiki code I could implement an
extended XWiki link syntax? E.g. if I'd like to handle something like
this:
Berlin is a city in [[locatedIn::Germany>>Germany]]
where I'm adding the double-colon syntax before the usual link info.
--
Mark Wallace
Principal Engineer, Semantic Applications
Modus Operandi, Melbourne, FL, USA
Hi all,
In order to allow XWikiAttachment to reference data in multiple places, we need XWikiAttachment to
know the location of it's content. XWikiAttachmentContent uses an id which is identical to the
XWikiAttachment id meaning XWikiAttachmentContent has no id of it's own, only a foreign key which
points to the content.
To remedy this I propose the addition of a UUID hibernate UserType. This type will store a UUID as a
16 byte VARBINARY entry (little endian encoding) in order to minimize the size and database load.
Note: I discovered that a UUID type was added in a later version of hibernate so when we upgrade we
can decide whether to begin using their implementation.
I would like to add the UUID type as the first class in a new module xwiki-store (in a submodule
called xwiki-store-hibernate).
I think the best approach is to add new database code to xwiki-store slowly until eventually the
storage drivers in the core are no longer used thus "moving a mountain one shovel full at a time".
The UUID implementation:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
How it works:
Add this to the xwiki.hbm.xml where you want to add a UUID:
<property name="contentUUID" type="org.xwiki.store.hibernate.types.UUIDToBinaryType">
<column name="contentuuid" />
</property>
(type can be mapped to a shorter name such as "UUID")
Add this to the bean class:
public UUID getContentUUID()
public void setContentUUID(final UUID contentUUID)
Hibernate takes care of the rest.
WDYT?
Caleb