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
Hello,
I would like to request a repository on xwiki-contrib for the Recruitment
Application i am working on.
I'd like the repo to be named application-recruitment and also jira
component.
My github username is chalx.
Thank you,
Alexandru Chelariu
Hi guys,
I have pushed a first version of flamingo in platform/XE, but it is only a
prototype that need a LOT more do be ready for production.
One of the new things brought by flamingo is the "Applications" left bar,
which is not exactly the same thing as the Applications Panel we already
have.
We can see it more as a "dock" with a list of applications, and in the
future, we could make it customizable by the user. Caty has written a
proposal for this [1].
Right now, for the first implementation, I need to make some choices about
the way we "populate" this bar. We can create new classes to describe the
bar entries, or new UI Extensions (maybe not the good choice regarding the
recent e-mails...), or by re-using the existing AddApplicationUIX... It is
described on
http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar#HImplementationConsi….
Other thing: In my draft, I have created a new VM file on the filesystem
for this concept. Maybe I should create it as an extension point stored in
the database, but it means it won't appear on an empty wiki. WDYT?
I let you make some comments about this.
Thanks,
Caty & Louis-Marie
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar
Hi everyone,
On the 15th of December (i.e. in a month's time), it will be **10 years**
since the first commit on the XWiki open source project.
Ludovic did the first commit in CVS on Sourceforge:
"
15.12.2003 10:13:33, by ludovic
Initial revision
"
(Can be seen at
http://svnsearch.org/svnsearch/repos/XWIKI/search?from=20030101&to=20040101
)
10 years is starting to be some respectable milestone!
I invite everyone to join us in celebrating by adding your own story about
your interaction with the XWiki community or the XWiki software at
http://dev.xwiki.org/xwiki/bin/view/Drafts/TenYearsOfXWiki
<XWiki SAS hat>
Since I'm also the CTO of the XWiki SAS company, I'd like to officially
invite all the members of this great community to join us in celebrating
the 10 days of the XWiki project at the XWiki SAS office in Paris, France
on the 12th of December 2013.
Here's the invitation:
http://www.xwiki.com/lang/en/News/XWiki+10th+Anniversary
See you there!
</XWiki SAS hat>
Well done everyone!
-Vincent Massol
Hi devs,
Running mvn dependency:dependency-analyze produces interesting results.
For example:
[INFO] ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[INFO] Building XWiki Commons - Properties 3.2-SNAPSHOT
[INFO] ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
…
[INFO] --- maven-dependency-plugin:2.3:analyze (default-cli) @ xwiki-commons-properties ---
[WARNING] Used undeclared dependencies found:
[WARNING] org.slf4j:slf4j-api:jar:1.6.1:compile
[WARNING] javax.inject:javax.inject:jar:1:compile
[WARNING] Unused declared dependencies found:
[WARNING] org.xwiki.commons:xwiki-commons-component-api:jar:3.2-SNAPSHOT:compile
[WARNING] org.xwiki.commons:xwiki-commons-test:jar:3.2-SNAPSHOT:test
[WARNING] org.hibernate:hibernate-validator:jar:4.2.0.Final:test
[WARNING] org.hamcrest:hamcrest-core:jar:1.1:test
[WARNING] org.jmock:jmock:jar:2.5.1:test
The question is (for this module but more generally for all others):
* Should we add slf4j and javax.inject reps in the pom.xml for this module? (for ex today slf4j and javax.inject are found in the component-api dep)
I think we should, wdyt?
Note that the "Unused declared dependencies found:" doesn't always generate correct results as is the case here. This is mostly because it's a static byte code check so any dep used at runtime will be considered unused.
See http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependen…
Thanks
-Vincent
Hi devs,
I’ve noticed a recurring trend from our users: a lot of them seem to wish to display Tree views/navigation view of their wiki pages either in page content or in a panel.
When they go to e.x.o, there’s a lot of extensions listed (showing that other users had this need previously) but none really work well:
http://extensions.xwiki.org/xwiki/bin/view/Extension/WebHome#|t=extensions&…
We do have a tree view in AllDocs but it’s not perfect and it’s not easily reusable.
Thus I believe we need to find an official solution to this tree view issue.
The easiest solution could be to create a wiki macro based on our current tree view so that it can be reused in wiki pages and more importantly in a panel. Having a “spaces” parameter to restrict the list of spaces to display would be nice too.
WDYT?
Any other idea?
Thanks
-Vincent
Hi devs,
This mail is about voting to drop support for IE8 in 6.x cycle.
The issue is more complicated, since according to our 'Browser Support
Strategy' [1] we are supporting IE8, IE9 and the latest versions of FF,
Chrome (+ Safari5).
IE8 was released in March 2009 (4 years ago)
IE9 - March 2011 (2 years ago)
IE10 - Sept 2012 (17 months ago)
IE11 - Oct 2013 (4 month ago)
With the release of IE11 some companies also dropped their support for IE9,
so we should also adjust our support strategy by supporting newer browsers
(IE10, IE11) and dropping the support for old ones (IE8, IE9).
According to Statcounter for the last 6 month period
http://gs.statcounter.com/#browser_version-ww-monthly-201309-201402-bar the
most popular IE browsers are IE10 (8.48%) and IE8 (7.98%).
While the market share is not neglectable there is something you need to
consider:
In 6.x we want to add a new skin: Flamingo. Ideally this skin should be
responsive. In order to assure responsiveness we need media query support.
IE8 doesn't has support for media query natively, we would need Respond.js
[2] to enable it.
While this solution exist, 6.x will be ready at the end of 2014 when I
suspect the market share for IE8 will drop.
Additional to not having media query support, there are other CSS3
properties and HTML5 elements that are not fully supported by IE8
(border-radius, box-shadow, transition, etc.).
This is my +1 to drop support for IE8 in 6.x
Thanks,
Caty
[1] http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy
[2] https://github.com/scottjehl/Respond
Hi devs.
In the coming 5.3 milestone 2, all wikis are displayed in the Wiki Index,
including the templates, which was not the case before.
>From the user point of view, maybe these templates should not be listed in
the Wiki Index. But on the other hand, if you want to see a template, you
will not be able to access through the wiki index.
We also have introduced the "hidden" flag for wikis (in the WikiDescriptor,
not in the UI yet). If we consider template wikis are "technical" wikis, we
may use this flag to hide them. Then, in the Wiki Index, we don't care if a
wiki is a template or not, we only care about the "hidden" flag. If the
user does not want to see the templates in the list, she can mark them as
hidden, exactly as we do for documents.
But what about the template list in the wiki creation wizard? Should we
list all templates, or only the visible ones?
My proposition:
- all wikis are visible though the wiki index (template or not).
- if we want to hide templates to the users, we use the hidden flag in the
wiki descriptor.
- in the wiki creation wizard, we display all the templates, even these
which are tagged as hidden.
WDYT?
Thanks,
Louis-Marie
I have some groovy code and in it I am grabbing the value from a field and
storing it in an object. When the value has spaces, it is encoded with
" ". Is there a way to remove HTML encoding from a string? I looked
in Util and didn't see anything.
Thanks.
--
View this message in context: http://xwiki.475771.n2.nabble.com/Decode-HTML-tp7589862.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
I am trying to modify the following code so when the user enters a new
documentName, it will set the title and rename the document. If I uncomment
the saveDocument line, it works. So I know the rest of the code is working.
Can anyone see what I am doing wrong?
{{groovy}}
import org.xwiki.observation.*
import org.xwiki.observation.event.*
import org.xwiki.bridge.event.*
import org.xwiki.context.*
import com.xpn.xwiki.web.*
import com.xpn.xwiki.*
import org.apache.velocity.VelocityContext;
class ProcessDocumentRenamer implements EventListener
{
def xwiki
def context
ProcessDocumentRenamer(xwiki, context)
{
this.xwiki = xwiki
this.context = context
}
String getName()
{
// The unique name of this event listener
return "ProcessDocumentRenamer"
}
List<Event> getEvents()
{
// The list of events this listener listens to
return Arrays.asList(new DocumentCreatedEvent(), new
DocumentUpdatedEvent())
}
// Called by the Observation Manager when an event matches the list of
events returned
// by getEvents()
void onEvent(Event event, Object source, Object data)
{
// Current context
def crtContext =
Utils.getComponent(Execution.class).getContext().getProperty('xwikicontext')
// Defines the type of object that should be looked for
def myObject =
source.getObject("DocumentationTemplates.ProcessClass");
// If the page has an object of the specified class, we get the
value of the relevant property and assign it to our documentName variable
if (myObject != null) {
// Defines the variable that we will later use to update the title
of the document
def documentName = myObject.get("processName").value
// Defines the Complete name we will use later when we rename the
document.
def FullDocumentName = source.getWikiName() + "!" +
source.getSpaceName() + "." + documentName;
// If the name has changed, we need to update and rename the
document.
if (source.getName() != documentName) {
source.setTitle(documentName)
// Force the storage to keep the same version number, so that
this looks like a single save event
source.setMetaDataDirty(false);
source.setContentDirty(false);
// crtContext.getWiki().saveDocument(source,
source.getComment(), source.isMinorEdit(), crtContext);
crtContext.getWiki().renamePage(source, FullDocumentName);
}
}
}
}
// Register against the Observation Manager
def observation = Utils.getComponent(ObservationManager.class)
observation.removeListener("ProcessDocumentRenamer")
def listener = new ProcessDocumentRenamer(xwiki, xcontext)
observation.addListener(listener)
{{/groovy}}
--
View this message in context: http://xwiki.475771.n2.nabble.com/Looking-for-help-with-groovy-tp7589782.ht…
Sent from the XWiki- Dev mailing list archive at Nabble.com.