- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [VOTE] Allow anyone to use org.xwiki.query.Query#setWiki

by Thomas Mortagne

Hi devs, When Query Manager as been introduced by Artem I suggested to add a setWiki to make easier to execute request on another wiki. For me it was supposed to be usable by anyone and I discovered recently that it was allowed only when the user has programming right. Since I really don't see the point I propose to remove this check. * all the users without programming right can do is to list documents names so it's not very dangerous * api;XWiki#searchDocumentsNames(String wikiName, String parameterizedWhereClause, int maxResults, int startOffset, List< ? > parameterValues) does not have any check so what the query manager prevent is doable anyway WDYT ? Here is my +1. -- Thomas Mortagne

13 years, 4 months

4
6
0 0

[xwiki-devs] [PROPOSAL] Use relative URLs instead of external URLs with sendRedirect

by Thomas Mortagne

Hi devs, In HTTP specifications a redirect is always absolute URL which is probably why we use absolute URL with sendRedirect. However sendRedirect does not produce direct HTTP response but allows relative URL and delegate to the application server the job of producing proper absolute URL. IMO XWiki should always use relative URL everywhere it can so I propose to change our practice to use relative URL instead of absolute URL with HttpSevletResponse#sendRedirect when possible. The only reasons I see to use external URLs are: * interwiki URL in a domain based multiwiki * html/pdf export for links pointing on not exported pages or non view actions WDYT ? Here is my +1. We very often fix bugs in the way to produce external URL and it's still not OK (see http://jira.xwiki.org/browse/XWIKI-7632) so lets reduce the scope for this need as much as possible. -- Thomas Mortagne

13 years, 4 months

6
20
0 0

Re: [xwiki-devs] [xwiki-notifications] [xwiki/xwiki-enterprise] 6e0258: [misc] Display hidden documents for Admin user bec...

by Vincent Massol

Hi Marius, On May 2, 2012, at 7:10 PM, GitHub wrote: > Branch: refs/heads/master > Home: https://github.com/xwiki/xwiki-enterprise > Commit: 6e0258a75e0e666db2f48672bcdb41bbefe0b717 > https://github.com/xwiki/xwiki-enterprise/commit/6e0258a75e0e666db2f48672bc… > Author: Marius Dumitru Florea <marius(a)xwiki.com> > Date: 2012-05-02 (Wed, 02 May 2012) > > Changed paths: > M xwiki-enterprise-test/xwiki-enterprise-test-wysiwyg/src/test/it/org/xwiki/test/wysiwyg/framework/WysiwygTestSetup.java > > Log Message: > ----------- > [misc] Display hidden documents for Admin user because various WYSIWYG tests use hidden documents. > > > diff --git a/xwiki-enterprise-test/xwiki-enterprise-test-wysiwyg/src/test/it/org/xwiki/test/wysiwyg/framework/WysiwygTestSetup.java b/xwiki-enterprise-test/xwiki-enterprise-test-wysiwyg/src/test/it/org/xwiki/test/wysiwyg/framework/WysiwygTestSetup.java > index 690daf1..97689c4 100644 > --- a/xwiki-enterprise-test/xwiki-enterprise-test-wysiwyg/src/test/it/org/xwiki/test/wysiwyg/framework/WysiwygTestSetup.java > +++ b/xwiki-enterprise-test/xwiki-enterprise-test-wysiwyg/src/test/it/org/xwiki/test/wysiwyg/framework/WysiwygTestSetup.java > @@ -55,6 +55,9 @@ protected void setUp() throws Exception > return; > } > > + // Make sure the hidden documents are displayed to the Admin user. > + displayHiddenDocumentsForAdmin(firstXWikiTest); > + > // Set up the WYSIWYG tests using the first WYSIWYG Test case for Selenium and skin executor API. > enableAllEditingFeatures(firstXWikiTest); > } > @@ -82,14 +85,28 @@ private AbstractWysiwygTestCase getFirstWysiwygTest(Test test) > } > > /** > + * Sets the Admin user preference to display the hidden documents. > + * > + * @param helperTest helper {@link AbstractWysiwygTestCase} instance whose API to use to do the setup > + */ > + private void displayHiddenDocumentsForAdmin(AbstractWysiwygTestCase helperTest) > + { > + helperTest.loginAsAdmin(); > + helperTest.open("XWiki", "Admin", "edit", "editor=object"); > + String propertyId = "XWiki.XWikiUsers_0_displayHiddenDocuments"; > + if (!"1".equals(helperTest.getSelenium().getSelectedValue(propertyId))) { > + helperTest.setFieldValue(propertyId, "1"); > + helperTest.clickEditSaveAndContinue(); > + } > + } Shouldn't this API be added to the UserProfile PageObject instead? Thanks -Vincent

13 years, 4 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] [xwiki/xwiki-commons] 6ecb13: XCOMMONS-162: Add start and end data to job status

by Vincent Massol

Hi Thomas, On May 2, 2012, at 6:48 PM, GitHub wrote: > Branch: refs/heads/master > Home: https://github.com/xwiki/xwiki-commons > Commit: 6ecb131081233764ed773eb84f9be34e23edb888 > https://github.com/xwiki/xwiki-commons/commit/6ecb131081233764ed773eb84f9be… > Author: tmortagne <thomas.mortagne(a)gmail.com> > Date: 2012-05-02 (Wed, 02 May 2012) > > Changed paths: > M xwiki-commons-core/pom.xml > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/AbstractJob.java > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/Job.java > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/JobManager.java > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/event/status/JobStatus.java > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/internal/DefaultJobManager.java > M xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/internal/DefaultJobStatus.java > > Log Message: > ----------- > XCOMMONS-162: Add start and end data to job status > XCOMMONS-163: Add join method to Job > > > diff --git a/xwiki-commons-core/pom.xml b/xwiki-commons-core/pom.xml > index 799f042..2251f94 100644 > --- a/xwiki-commons-core/pom.xml > +++ b/xwiki-commons-core/pom.xml > @@ -115,6 +115,8 @@ > <exclude>**/internal/**</exclude> > <exclude>**/test/**</exclude> >  > + <exclude>org/xwiki/job/Job</exclude>  > + <exclude>org/xwiki/job/event/status/JobStatus</exclude>  This goes against the deprecation/legacy strategy we have voted since we said we will not add *any* breakage. It's not allowed anymore to have any exceptions in CLIRR. (See http://markmail.org/message/tino4ngttflc5i3s). So you need to go through a deprecation strategy and move this to legacy. Alternatively you should make a new proposal to amend our backward-compatibility strategy for "young" apis. I'll start the thread for you but in the meantime all Release Manager need to be very careful to not perform new releases when there are CLIRR excludes since it means we have broken backward compatibility. Thanks -Vincent

13 years, 4 months

2
3
0 0

[xwiki-devs] [Brainstorm] What do we do with the AutoTag plugin?

by Vincent Massol

Hi devs, Sergiu has extracted the AutoTag plugin from oldcore in its own module. That's cool. However he's also marked it @deprecated while doing so. And he's stopped bundling it in XE. This raises several question: 1) Do we consider that what the plugin does it not useful? Because if we consider it's useful we might not want to deprecate it without offering an alternative. It's not because a technology is deprecated that we should deprecate stuff using that technology. Deprecated means: don't use this, instead use that. BTW it should be our rule that when we add the @deprecated tag we also mention what to use instead. 2) If we consider it's not useful anymore. We have 2 choices: 2a) Move it in legacy modules 2b) Move it to retired/contrib My opinion: * It could be useful but I'm not sure the XWiki Dev team wants to support it. IMO it should not be deprecated since it can still be useful and there's no replacement for it. * Since I don't think the XWiki Dev Team should support it, I'd move it to xwiki-contrib/retired and publish it on e.x.o. for users who want to still use it. * Since this is breaking our new rule regarding deprecations/legacy it requires a VOTE to move it to contrib/retired. It also needs to be clearly mentioned in the Release Notes as a breakage and explain how user can add it back to their wikis. Let me know what you think and I'll send a VOTE if you agree with what I said above. Thanks -Vincent

13 years, 4 months

4
3
0 0

[xwiki-devs] [Announcement] XWiki Enterprise and XWiki Enterprise Manager 4.0 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 4.0. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the first release of the 4.x cycle. See http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap for more informations about the 4.x cycle. The highlights of this release are: * reduced document database id collision. It has been well tested but you might want to make sure you have a working backup of your database. * new LDAP administration UI * Annotations merged with Comments * Extension Manager improvements * App Within Minutes improvements * User profile customization * User directory improvements and user customized view * ColorThemes gradients customizable from ColorTheme Wizard * New IRC Bot Application On development side: * Extension Manager (without xar support and wiki UI) is now part of XWiki Commons project and can be easily used outside of XWiki * Component roles are now based on java.lang.reflect.Type instead of java.lang.Class which mean you can now have different roles with the same class and different generic types (e.g. ) * New Velocity tool to serialize Java objects to JSON format * Class reference always local * New Rights Implementation (Experimental). You can enable and test it in xwiki.cfg. * New technical content hiding system * A new ApplicationReadyEvent event has been introduce for component that need to access the database at init. For more information see the Release notes at http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise40 and http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXEM40 Thanks -The XWiki dev team

13 years, 4 months

2
2
0 0

[xwiki-devs] [VOTE] Stop bundling the Event Syntax in XE?

by Vincent Massol

Hi, I've now put the Event Renderer in its own syntax module, same as what we have for other syntaxes. Thus we need to decide if we still want to bundle it in XE or not (it was bundled but only because it was in rendering-api before). IMO there's no reason to bundle it at all since: * it's not used anywhere * I don't see any use case for it (we use it only for tests) * We want to reduce the # of extensions we bundle by default * It can be added by the user in his XE instance should he need it (I doubt it) So here's my +1 to not bundle it and to add this potential backward compat breakage in the RN for 4.1M1 Thanks -Vincent

13 years, 4 months

5
4
0 0

[xwiki-devs] WYSIWYG toolbar features

by Geo Du

Hi, all, I have a problem to add more tools onto the toolbar with xwiki 3.5 I am using, I like to add Text Alignment, Fonts, TextSize, colors, but I checked this link:http://platform.xwiki.org/xwiki/bin/view/Features/WysiwygEditor, it is for 2.0, where is the toolbar configuration information about the 3.5 version? I could not find from the admin guide. Also from the WYSIWYG editor configuration class, https://sipa.mol.fi/xwiki/bin/view/XWiki/WysiwygEditorConfigClass, it does not define all the tool bar items. Would you please point me to the right direction to look at? Thanks very much!! Dave

13 years, 4 months

1
0
0 0

[xwiki-devs] [Announcement] XWiki Enterprise 3.5.1 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.5.1. This is the first bugfix release for the 3.5 series, and, since 3.5 is the final major release in the 3.x cycle, a bugfix release for the whole 3.x cycle. The main focus has been on quality assurance, improving the compatibility with various database systems, polishing the new sheet mechanism, the new extension manager, the skin, the WYSIWYG, and other parts of the XWiki platform. See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise351 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 4 months

1
0
0 0

[xwiki-devs] [Reminder] Deprecation day tomorrow (26th of April)

by Vincent Massol

It's tomorrow, the 26th of April, don't forget! Goal: * Move as many deprecations to legacy modules Who: * All committers and all contributor who wish to help out Metric: * Our score will be the # of APIs moved. Each dev need to report the # of APIs he's moved. Let's make it a success and learn from it. I'll publish a blog post with the result afterwards. Thanks -Vincent

13 years, 4 months

5
13
0 0

[xwiki-devs] XWiki databases testing helper script and repository for unreleased but maintained codes

by Denis Gervalle

Hi devs, Following the numerous database related issues that have/are delayed/ing the 3.5.1 release and the 4.0 release, and seing how it could be long and annoying to put multi-database tests in place, and the hard work Sorin has done in testing these issues again and again, I have taken a couple of hour to write a decent bash script. Here is an excerpt of the usage message of my script: This script can do the following steps easily to help you testing xwiki distribution: - Download a distribution package, either release or snapshot (using mysql/jetty distribution). - Deploy that package, and configure it for a requested database. - Create the needed database. - Import a database dump, previously exported with this same tool. - Launch the configured XWiki with Jetty. - Backup the database after XWiki shutdown. All operations could be done in a multiuser environment, using common databases, without conflict. You may start using it as easy as "xwiktest -v 3.5 -d oracle -w" to have a XWiki release 3.5 downloaded and run with oracle and non-conflicting ports and database. Full options are listed at the end of this thread for the interested. I really hope this script could help in testing more often any changes that may have consequences between versions, or may cause incompatibilities with some databases. It would be nice if a well connected VM (the one from Sorin has all DBs well configured but is badly connected and downloading is really slow :( ) could be available to all committers, avoiding each one to have to setup each database locally. If you find it useful, I will maintain this script as much as possible, and improve it further. I have already some idea like: - automatically import a given XAR - check logs, terminate and report issue automatically (to integrate with Jenkins?) - allow starting multiple version one after each others, testing migration in one run ... This is already more than a simple script (~500 lines), and well documented. However, I do not found a good place to put such script in GitHub. IMO, this script is like release scripts, it will be maintained by the dev team, and it could became essentiel to the project, and I have conform as much as a bash script could to our coding practices. Therefore I do not think that putting it in xwiki-contrib is right. Release scripts should not even be there, and need a place in a xwiki repositories IMO. These are scripts that are never released nor compile or what ever. We have already something similar in xwiki repositories: xwiki-debug-eclipse I do not think it is nice to multiply repositories in xwiki, but there is a need for unreleased but maintained codes like these. I proposed that we create a new repository in XWiki to contains such codes, and to put/move in it: - xwiki-debug-eclipse - xwiki-release-tools (for release scripts) - xwiki-testing-tools (for the above script) We may call this repository: - xwiki-tools - xwiki-utils - xwiki-dev-tools ... WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO As promised for the curious, the options of my testing script: Usage: xwikitest [OPTIONS] Options: -b backup.sql Backup database to the given file (or folder for oracle) after shutdown. -B backup.sql Backup current database to the given file, same as -b -z -k -n -d database Choose a database (mysql-myisam,mysql-innodb,psql,oracle,hsqldb). Current is mysql-innodb. -e distribution Choose a distribution (enterprise or manager). Current is manager. -i dump.sql Import the given sql dump in the database before startup. -I dump.sql Import the given sql dump in the database without running, same as -i -z -n -h Display this usage message. At the end, it shows your current arguments and alone the defaults. -k Do not clean the database before startup. -n Do not start XWiki. -p port Port for Jetty listening. Current is 7581. -r snapshot Use given snapshot (ie: 20120410.161114-97). Default to use release. -s dbsuffix Database suffix for test isolation. Current is DenisG. -t port Port for Jetty termination. Current is 7501. -v version Choose a XWiki version. Current is 4.1. -w Download from maven.xwiki.org. Default is to search current folder. -z Do not redeploy and reconfigure (use with care).

13 years, 4 months

3
2
0 0

[xwiki-devs] jQuery is undefined error for IE7

by Geo Du

Hi, all, I am using jQuery for javascript, since it is conflicting with prototype, I use the jQuery help extension: http://extensions.xwiki.org/xwiki/bin/view/Extension/jQuery+Helpers, so far everything works fine on Firefox, the problem is the IE7, I got jQuery is undefined error from the UI library: $xwiki.jsx.use("jQuery.jQueryUI"), I can see the javascript code in firebug with last par of the code: .bind("blur",h)})})})(jQuery); I noticed that there is a ";" in the end, but in IE7, I checked the code from Microsoft Script Editor when I debug, it shows no ";", not sure if that is the problem. In IE7, I clicked the jQuery helper extension demo pages: bin/view/jQuery/Demo1 page and bin/view/jQuery/Demo2 page, they both gave me "jQuery is undefined" error. so this error happens to the extension as well. Could anybody help me with is issue? Thanks very much. Dave

13 years, 4 months

1
1
0 0

[xwiki-devs] [VOTE] Legacy Module Rules

by Vincent Massol

Hi devs, In preparation of our Deprecation Day and continuing our vote on the Deprecation strategy I'd like to propose several rules we need to clarify since we need them and I'd like to finish documenting our full deprecation strategy. Rule 1: Where are Legacy modules located? =================================== * Proposal: - Each Git repository needing legacy modules provides a *-legacy module for holding legacy modules. For example: -- For Commons, xwiki-commons-core/xwiki-commons-legacy/ -- For Platform, xwiki-platform-core/xwiki-platform-legacy/ -- For Rendering, xwiki-rendering-legacy/ * Explanation: - It's better to locate them in a specific module (*-legacy) than inside their own module (for ex in xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/) because legacy modules are something we don't want to see as much as possible since we're must not use them in our code, thus it's logical to park them all together somewhere. * Notes: - This is our current rule but it's never been explicitly defined Rule 2: What do Legacy modules contain? ================================= * Proposal: - Each Legacy module should replace the non-legacy module it corresponds to. This means that the user must have only 1 JAR for a given module: either its legacy version or it's non-legacy version but should never have both. * Explanation: - We need consistency. Right now we have oldcore which acts like this but others don't and it's complex to explain to users that for some they have to swap them and for others they have to keep both side by side - In the very close future, we'll use a lot of Aspects in modules others than legacy-oldcore, and thus we'll need to apply this strategy anyway. * Notes: - Currently, only oldcore acts like this. - The consequence is that we'll have one legacy module per non legacy modules. Right now we sometimes have one legacy module for several non legacy modules which we'll need to fix Here's my +1 to both. Thanks -Vincent

13 years, 4 months

3
7
0 0

[xwiki-devs] [VOTE] Changing our deprecation strategy (TAKE2)

by Vincent Massol

Hi devs, I had started a first VOTE: http://markmail.org/thread/56v5thsj6wv7tpno But since that first VOTE transformed into a brainstorming I'm starting a new VOTE below with the result of our brainstorming: * Distribute without legacy modules by default * Document how users can add legacy modules and make that visible from the download page somewhere. * Move deprecated APIs to legacy modules as soon as our code is clean and stops using the newly deprecated APIs * Never remove APIs from the legacy modules by default but when we really need to do so (for some technical reason for example), do it on a case by case basis and send a VOTE to do so This ensures that: * New users quickly use the newest APIs (they won't even see the old APIs by default). * Older users are not broken since they can add the legacy modules * When someone upgrades he can easily try using the new distribution without legacy and if it breaks some of his code he can either fix his code or add the legacy modules Here's my +1 Thanks -Vincent

13 years, 4 months

4
5
0 0

[xwiki-devs] Simple Mobile Skin

by Ludovic Dubost

Hi, I've been working a while ago on a Mobile Skin which principle is the following: 1/ Light UI adapted to mobile devices, both phones and tablet (with a particular attention to tablets), giving most of the screen real estate to the page content 2/ Support all Javascript normally supported in the XWiki skin in order for any code inside pages that would use this Javascript to still work 3/ Automatic detection of mobile devices to make them switch to the mobile skin 4/ Ability to switch from mobile to normal skin 5/ compatibility with color themes I believe this approach is the right one, as XWiki instances do have significant Javascript and in order to make sure these pages work, we need to be able to accept this javascript. Of course some other improvements could be done, for example to have a mobile friendly dashboard or livetable. Now this work has had a few iterations with particularly some relooking work from Caty. The work is published here: http://extensions.xwiki.org/xwiki/bin/view/Extension/SimpleMobileSkin And the code is available here in both XAR and File-System version (for XEM): https://github.com/ldubost/xwiki-mobileskin The skin can be tested on the incubator (although there is not the automated switch) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/34Proposal?skin=XW… I've also worked on integrating this in the platform. The commit is available in a fork on github: https://github.com/ldubost/xwiki-platform/commit/064baeb017b35e08a526029381… I'd like some comments and discussion so that we can bring this into the platform. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 4 months

3
7
0 0

[xwiki-devs] [Proposal] Changes to Page Creation needed for Application Within Minutes

by Marius Dumitru Florea

Hi devs, For the upcoming Application Within Minutes I need to enhance the XWiki platform with the ability to generate the page name automatically when creating a new wiki page. For some applications it doesn't make sense to have two creation steps: (1) specify the wiki page name (i.e. the location) and then (2) edit the new wiki page with the specified name. Let me give you two examples: * It would be cool to be able to create a new blog post in a single step. The blog post name could be generated from the blog post title specified in the edit form. * An application that manages holiday requests doesn't need meaningful page names (i.e. free text, like a blog post would have) but something like Request_XYZ, where XYZ is a unique counter/identifier. These applications should be able to create new wiki pages with automatically generated names without writing their custom create forms. Since 3.2RC1 was planed for today and these changes are in the 3.2 roadmap, here's a proposal that I think I can implement quickly and safely: (1) Introduce two new components: // Used to generate a document name that doesn't have to be unique (e.g. by cleaning the document title). DocumentReferenceGenerator#generate(DocumentModelBridge):DocumentReference // Used to make a document name unique (by suffixing an unique counter/identifier) DocumentReferenceDifferentiator#differentiate(DocumentReference):DocumentReference (2) Modify editinline.vm to store "documentReferenceGenerator" and "documentReferenceDifferentiator" request parameters in two hidden input fields so that they are passed to the save action. Obviously, these are component hints. (3) Modify editactions.vm to replace "Save & View" + "Save & Continue" with "Create" when "documentReferenceGenerator" or "documentReferenceDifferentiator" (or both) request parameters are set. (4) Modify SaveAction to take into account these two request parameters (only if they are specified). Something along these lines: generateDocumentReference(doc) synchronize(lock) { doc.copyDocument(differentiate(generatedDocumentReference)).save(); } I'm not sure where to place the two components from (1) though. WDYT? Thanks, Marius

13 years, 4 months

8
14
0 0

[xwiki-devs] How to call rendering component ?

by jerem

Hello, In velocity I was using : $services.rendering.parse(...) $services.rendering.render(...) My question is : how can I inject the component to do that from a java component, specifying the parser/syntax ? I just had a quick look to the tests but they use the componentManager while I preferred to use annotations until now, so I'm a bit lost ... :) Thanks Jeremie -- View this message in context: http://xwiki.475771.n2.nabble.com/How-to-call-rendering-component-tp7487904… Sent from the XWiki- Dev mailing list archive at Nabble.com.

13 years, 4 months

2
6
0 0

[xwiki-devs] New XWiki Commons Groovy Module

by Vincent Massol

Hi devs, I'd like to add a Groovy Module in XWiki Commons. We need this module to provide customization for the Groovy JSR223 implementation to support Groovy Compilation Customizers, see http://groovy.codehaus.org/Groovy+1.8+release+notes#Groovy18releasenotes-Co… See also: * http://jira.xwiki.org/browse/XCOMMONS-153 * http://jira.xwiki.org/browse/XWIKI-7755 I'm going to add it in my next commits. Please should if you think it's not a good idea. Thanks -Vincent

13 years, 4 months

1
1
0 0

[xwiki-devs] Create Page button redirected to localhost

by du du

Hi, all, I logged in as an administrator, I like to create a new page under jQuery with this URL: http://mydomain/xwikim/bin/create/jQuery/WebHome when I click the Create button, it always redirected me to localhost as following: http://localhost/xwikim/bin/edit/jQuery/jQueryUICustom?template=&parent=jQu… which caused error message: Unable to connect, I tried to create from Main space, also the same problem and redirected me to: http://localhost/xwikim/bin/edit/Main/jQueryUICustom?template=&parent=Main.… when this happens, I have to replace the localhost with mydomain on browser address and press enter to bring up the page, this happened to me many times when I need to do edit action, when it is view action, it works perfectly, I have httpd apache webserver in front of tomcat, in apache config file, my setup is: ProxyPass /xwikim http://localhost:8082/xwikim ProxyPassReverse /xwikim http://localhost:8082/xwikim In tomcat server.xml file, the setup is: <Connector port="*8082*" maxThreads="*150*" minSpareThreads="*25*"maxSpareThreads ="*75*" enableLookups="*false*" acceptCount="*100*" connectionTimeout="* 20000*" proxyPort="*80*" disableUploadTimeout="*true*" /> I feel this setup should be ok, since it works all the time except sometimes it does not work for edit action or login. Does anybody have ideas about what happened and how to fix? Thanks very much in advance. Dave

13 years, 4 months

1
0
0 0

[xwiki-devs] [PROPOSAL] Determine that it's a new or out of sync instance

by Thomas Mortagne

Hi dev, To get a proper setup of installed extensions we want to make sure everything is installed trough Extension Manager instead of being imported as a plain xar. So the idea come up to finally start the long awaited installer/upgrader UI. First step is to find how to know when to display this UI so here is a proposal (ref http://dev.xwiki.org/xwiki/bin/view/Design/Installerandupgrader): = The new informations * deprecate version.properties for a more complete distribution.properties that would contains at least the following ** version of the distribution ** top extension id of the distribution (to display general informations about the distribution). For example in XE it would be distribution.id=xwiki-enterprise ** name of the distribution (I'm not 100% sure for this one since we can find it with the id using Extension Manager but I think it's safer in case we don't have access to any repository to display something nicer than a technical id). For example for XE it would be distribution.name=XWiki Enterprise (who would have guessed :)). ** war extension id of the distribution (generate a default id like <product-id>-web when none is provided). For example in XE it would be distribution.web.id=xwiki-enterprise-web ** ui extension id of the distribution (generate a default id like <product-id>-ui when none is provided). For example in XE it would be distribution.ui.id=xwiki-enterprise-ui ** then come custom properties specific to the distribution. For example in XE I think we could add commons.version, rendering.version, etc. = The current informations * store all that in a table of the DB to compare the current with what comes with the war. If the DB does not contain anything its a new install, if the DB contain something different it's an upgrade (note that this also support downgrade or moving from one distribution to another like XE -> XEM the same way). The idea is that we store theses informations only when the installer/upgrader is fully passed or that the user explicitly indicated tat he does not want to install or upgrade anything so that if you only did part of it before restoring you can come back and continue the install/upgrade process. = The manager * introduce a xwiki-platform-distribution to manipulate all that = Some questions 1) "distribution" or "product" ? 2) reuse the same table where we currently store the DB version ? I don't want to talk about the installed/upgrader UI itself for now, it will be the subject of another mail. I would like to concentrate of one step at a time since that's going to be pretty important system. WDYT ? The may goal that started this proposal is the installer/upgrader UI but those as also very useful for different use case. Some lib could want to know the version of platform or commons to choose what to do, we will be able to add the id of the distribution itself and the war extension as core extension to allow some extension to put it as dependency, we will finally display a proper footer without putting the distribution name in the XWikiPreferences. Here is my +1. 1) my +1 goes to "distribution" 2) my +1 goes to another table to not mix different subjects Thanks, -- Thomas Mortagne

13 years, 4 months

5
8
0 0

[xwiki-devs] An edit problem

by jinlong liu

I use the xwiki 3.5.When I edit a long text(longer than one screen) with the wysiwyg, Every time I press t he enter button or insert a heading,it will jump t.o the head of the page which I am editing.Is there any solution to it or it is just a problem only I met

13 years, 4 months

2
1
0 0

Re: [xwiki-devs] [xwiki-users] xwiki:dom:loaded event callback function never got called

by du du

I tried to use wiki="false", or remove //<![CDATA[ and //]]>, still the event callback function never get called, any other reason? Thanks for your response, please help. Dave On Wed, Apr 18, 2012 at 5:33 AM, Marius Dumitru Florea < mariusdumitru.florea(a)xwiki.com> wrote: > Hi Dave, > > On Wed, Apr 18, 2012 at 6:43 AM, du du <dddu88(a)gmail.com> wrote: > > Hi all, > > > > I have the following velocity code in xwiki page, I can see the fid and > > fname values when I retrieve entryobj from the server side, so I want to > > use javascript to add the fid and fname to image link node as parameters > of > > the href url. the problem is the javascript loaded event function never > got > > called, why? > > > > Thanks very much. > > > > Dave > > > > {{velocity filter="none"}} > > {{html clean="false" wiki="true"}} > > <script type="text/javascript"> > > > //<![CDATA[ > > wiki="true" causes // to generate an EM HTML tag. Just look at the > page HTML source (all browsers have this option) and you'll see that > your SCRIPT tag is messed up. > > My advice is to: > > * use a JavaScript extension ( > > http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial#HM… > ) instead of in-line SCRIPT tag > * try to avoid HTML macro with wiki="true" or, if it's not possible, > try to reduce as much as possible its content, i.e. wrap only the code > that really needs it. > > Hope this helps, > Marius > > > document.observe("xwiki:dom:loaded", function(){ > > var imageNode = document.getElementById('tmViewImages'); > > var url = imageNode.href; > > var index = url.indexOf("?"); > > if(index!=-1) > > url = url.substring(0,index-1); > > url=url+"?FID=$!fid&FName=$!fname"; > > imageNode.href=url; > > > > //]]> > > </script> > > > > #getEntryItemObject($doc $entryObj) > > > > #if("$!entryObj" == '') > > #warning($msg.get('xe.blog.sheet.notpost')) > > ## Keep testing the inline action for backward compatibility with older > > blog posts. > > #elseif($xcontext.action != 'edit' && $xcontext.action != 'inline') > > ## View mode > > > > #set($fid=$entryObj.getProperty('FID').value) > > #set($fname=$entryObj.getProperty('FName').value) > > fid view: $fid > > fname view: $fname > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users >

13 years, 4 months

1
0
0 0

[xwiki-devs] Approach for extensions with multiple dependencies ?

by jerem

Hi all, Developping the mail archive, I realize that this app (that will consist of extension .xar + component .jar) will have many dependencies on other extensions. To cite only some, there will be : mktree, tabs, livetable export to excel, ratings, ... When possible I try to make these dependencies optional : if you want the related feature, install the extension and check the option (for ex. livetable export to excel). But some dependencies will be mandatory anyway. To prepare things correctly in advance, what is the best approach in this case ? Do I only need to list the dependencies, and prevent users that to install my app, they need to install the other extensions as prerequisites ? Can it be managed automatically by the extension manager during install of my app (it would install the others before) ? Or should I package all these inside my own app for sake of simplicity ? (but it's ugly) Thanks, Jeremie -- View this message in context: http://xwiki.475771.n2.nabble.com/Approach-for-extensions-with-multiple-dep… Sent from the XWiki- Dev mailing list archive at Nabble.com.

13 years, 4 months

2
1
0 0

[xwiki-devs] xwiki:dom:loaded event callback function never got called

by du du

Hi all, I have the following velocity code in xwiki page, I can see the fid and fname values when I retrieve entryobj from the server side, so I want to use javascript to add the fid and fname to image link node as parameters of the href url. the problem is the javascript loaded event function never got called, why? Thanks very much. Dave {{velocity filter="none"}} {{html clean="false" wiki="true"}} <script type="text/javascript"> //<![CDATA[ document.observe("xwiki:dom:loaded", function(){ var imageNode = document.getElementById('tmViewImages'); var url = imageNode.href; var index = url.indexOf("?"); if(index!=-1) url = url.substring(0,index-1); url=url+"?FID=$!fid&FName=$!fname"; imageNode.href=url; //]]> </script> #getEntryItemObject($doc $entryObj) #if("$!entryObj" == '') #warning($msg.get('xe.blog.sheet.notpost')) ## Keep testing the inline action for backward compatibility with older blog posts. #elseif($xcontext.action != 'edit' && $xcontext.action != 'inline') ## View mode #set($fid=$entryObj.getProperty('FID').value) #set($fname=$entryObj.getProperty('FName').value) fid view: $fid fname view: $fname

13 years, 4 months

1
0
0 0

[xwiki-devs] [Proposal] Implement "distinct" in XWQL short queries through a QueryFilter

by Jean-Vincent Drean

Hi devs, while replacing calls to xwiki#searchDocuments by calls to the query manager script service I ran into the following query manager issue: http://jira.xwiki.org/browse/XWIKI-7273 (XWQL short form queries should distinct on document fullname.) I think we could use the recent QueryFilter mechanism to handle the addition of the "distinct" in the select statement. https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi… QueryFilters allow to: - transform queries depending on a dynamic parameter (for example the user preferences in HiddenDocumentFilter) - transform the select part of a short query, without requiring programming rights Here's an example of what it could look like from a velocity script: ----------------------------------------------------8<---------------------------------------------------- #set($query = $services.query.xwql("").addFilter("unique").addFilter("hidden")) ----------------------------------------------------8<---------------------------------------------------- Note that in the future we could decide that the Query wrapper we use in the QueryManagerScriptService (ScriptQuery) have the "unique" filter by default + a way to remove it from the script. I wasn't expecting us to consider using multiple filters when I added the new APIs in Query (4.0RC1). If we agree that a QueryFilter would be a nice way to handle this, I'd like to break those API before we release 4.0: ----------------------------------------------------8<---------------------------------------------------- - Query setFilter(QueryFilter filter); + Query addFilter(QueryFilter filter); - QueryFilter getFilter(); + List<QueryFilter> getFilters(); ----------------------------------------------------8<---------------------------------------------------- WDYT ? JV.

13 years, 4 months

4
10
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs