xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] error using calendar application

by Daniel Bertinshaw

Hi, I have re-written the Xwiki.CalendarSheet code to add the calendar event object to $xwiki.getDocument("XWiki.CalendarSheet") rather than $doc (reason being, I want to include it in other contexts/pages). It works fine, until another user adds an event, then the events in the calendar display disappear, and re-appear if I edit the page and make no changes: oddly, the changes disappear for everyone and re-appear globally too. If I use my own account and add an even, there's no issue (im an admin, my test account is a normal user: I have tried fiddling with the rights). Any help? (code attached)

17 years, 2 months

[xwiki-devs] [Proposal] Improve installer to include database setup

by Vincent Massol

Hi, I'm proposing to improve the generic install to add database configuration setup: 1) include different database driver jars in the installer 2) have some installation panels to let the user choose the database to use (using some combo box and fields to modify default DB values) 3) include the XAR in the installer 4) use the packager tool to import the XAR in the database at install time (using the information provided in 2)) Note: I'd also like to modify the web/standard build so that we release only a single WAR without database driver and without DB configuration. Advanced users will configure it manually and novice will use the installer. WDYT? Thanks -Vincent

17 years, 2 months

[xwiki-devs] Lucene search enhancements

by David Ward

I've entered two bugs (XWIKI-1734 and XWIKI-1735) which relate to extending the Lucene Plugin search API. I would like to try getting them into the 1.1.1 version. The first is to allow Lucene to return the results in reverse order (one of the results columns we want to sort by is reverse alphabetical). The second is to index the creation and modification dates of the wiki pages (to allow "recently changed" type of searches limited by other criteria). The first is more important, but the second looks easy. David dward(a)curriki.org --

17 years, 2 months

[xwiki-devs] [Proposal] New GWT-based WYSIWYG editor

by Vincent Massol

Hi, I'd like us all to welcome Marius Dumitru Florea who has joined the XWiki dev community to work on a new GWT-based WYSIWYG editor. Marius is very new to the XWiki team so I'd like all of us to support him for this very important work. This is really just the start of this project so we need everyone's help in designing it and for providing feedbacks and ideas. I've started a page on it there: http://www.xwiki.org/xwiki/bin/view/Idea/NewWysiwygEditorBasedOnGwt I'll we working with Marius on this for the time being and Jean- Vincent will probably help us in the future too. And anyone willing to help is most welcome. As I've mentioned on that page we have 3 main issues with the current WYSIWYG editor so it's time to start fixing them. The current Tiny- MCE based editor as the following deficiencies: * Slow * Complex code using complex regexs. This leads to a fragility that makes it break somewhere whenever someone adds a modification to it. * Lots of bug reports consistently for the past year, showing a non- optimal design I'll kick-start the discussion with some open questions I've listed on that page: * Is there a GWT editor component we can/should reuse? * Check WikiModel capabilities for conversions in both directions and especially from HTML to wiki syntax. * How to integrate WikiModel in the Rendering layer of XWiki? * Is there any code to be salvaged from the work done by Christian and Nam in that branch: svn+ssh://svn.forge.objectweb.org/svnroot/ xwiki/xwiki-platform/core/branches/XWIKI_WYSIWYG_NEWARCHI If anyone has any insight on these questions, please speak up! :) Thanks everyone, -Vincent

17 years, 2 months

[xwiki-devs] XEM review

by Vincent Massol

Hi Thomas and everyone, I've started reviewing the XEM code in SVN in preparation for the 1.0M1 release for the 17th and I have the following questions/remarks (before putting them in JIRA): 1) Search.WebHome: This looks empty. Should it be removed or will there be something before 1.0M1 is released? 2) The XE XAR overwrites the XEM XAR in the build. I think it should be the other way around. 3) The XEM home page should be different than the XE one. It should mention things specific to XEM. 4) The Quick Links panel should be specific to XEM. 5) I think several XE pages should be removed from the default XEM. For example Photo Album is not something I'd think belongs to the XEM Administrator page by default. It would be belong to a subwiki for sure but not to the Admin one or at least not by default. This raises the question: what is the XEM administrator wiki for? Only for administrating subwikis or is it meant for other things too? 6) UserDirectory.WebHome is empty too 7) Utils space. Is that the right name for this space? From its content it look like some Admin space. 8) UserDirectory space. Wouldn't it be shorter and nicer to name this space: "Users" , and to name "Wikis" the space listing wikis instead of "WikiDirectory"? 9) The WikiDirectory.WebHome page shows the following which doesn't look very nice (especially the "listwikiempty" text): Wikis totalnumberofwiki : 0 createwiki Search listwikiempty 10) XEMAdmin.WebHome is empty 11) In XEMCode there's a XEMSkin document. Is it ready? If not we shouldn't keep pages that are not going to be released in 1.0M1 12) XWiki.SearchResults is not used/ + some other comments. Generally speaking it seems to me the default XEM wiki is not ready yet to be released. Also it would be nice if XEM had a different visual identity than XE. Do we have a skin in progress for it? Will it be ready for 1.0M1? I'm pretty sure I must be missing something (maybe there's a patch that hasn't been applied about XEM's XAR pages?)... :) These are just a few questions to get us started towards the 1.0M1 release of XEM. Thanks -Vincent

17 years, 2 months

[xwiki-devs] Problems with the Blog

by totoe

Hi! I have a big problem with my blog-function in my Wiki. I've delete all example posts over the wiki function and the blank categories over my SQL. My problem now is, that I cannot make new posts in the standard categories. If I click on "Create Blog Post", I can set the posttitle Name. That is normal... But then I click on "Create": I get the error message "This is not an article". What should I do? I really need the blog. I hope you can help me... Thanks for your help! Torben

17 years, 2 months

[xwiki-devs] [Proposal] Stable vs Unstable Platform Core for Products: point releases in branches

by Vincent Massol

Hi, Now that we're starting to have several products (XE, XEM, Watch, Curriki, etc) we need to agree on a strategy for their dependencies on the Platform Core. Need ===== Here's a real use case on which we can base our discussion: * XEM needs to be released ASAP. More specifically there's a need to release 1.0M1 on 17th of Sept. and 1.0M2 on 1st of October. * Platform Core 1.2 in trunk is not stable yet and will only be released at end of November (if we agree on the schedule I sent this morning) * XEM needs to use a stable Core * XEM needs some features in core that are not in Core 1.1 (For example: the new Right Management UI which needs to change templates and possibly some code too) To summarize, Products may require a stable version of the core but with modifications. How do we solve this? Solutions ======== Short term solution: * We put whatever is required in point releases. For example, for XEM, we put the Rights Management changes in 1.1.x * We decide on the 1.1.x release dates based on the aggregated needs of the different Products * Once the Core trunk is released then the Products are modified to depend on it. * Of course each Product should try its maximum to internalize required changes inside its own code rather while waiting for the Core the released. To do this, JIRA issues with patches should be submitted to the Core to be applied. The other short term solution is to have a specific branch of Core for each product but I feel this is going to be a nightmare to maintain and merge so I'd much rather have a single 1.1.x branch which we can release as fast as we want. Medium/Long term solution: * Make the Core more and more modular with components so that a Product can keep all the core except for a specific component for which it can have its own implementation for some time till that makes it inside the core. * Reduce Core release lifecycles. Right now it's 3 months. We could probably reduce that to 1.5 month right now. * In order to reduce that even further, have more automated functional tests in the Core so that we can release a stable release of the core every 2-3 weeks. Once we reach that stage, I think there won't be any need to have branches for products. However this requires a change of mind for XWiki core developers since developers would need to write tests as they commit code instead of committing stuff and then fixing them later on, in further betas or RCs. This is our Graal. Conclusion ========= Are we all ok to agree that the 1.1.x releases will thus contain changes/improvements (i.e. each change must be reviewed carefully so that it's not risky and does not endanger the stability of the branch)? Thanks -Vincent

17 years, 2 months

[xwiki-devs] [ANN] XWiki Enterprise 1.1 RC 2 Released

by Vincent Massol

The XWiki development team team is pleased to announce the availability of the 1.1 RC 2 release of XWiki Enterprise Go grab it on http://www.xwiki.org/xwiki/bin/view/Main/Download This is a bug fix release and is meant to be the last RC. If no major bugs are found for 2-3 days it'll be promoted as the 1.1 final release. Please help us in testing it. Release notes: http://www.xwiki.org/xwiki/bin/view/Main/ ReleaseNotesXWikiEnterprise11RC2 Enjoy -The XWiki development team

17 years, 2 months

[xwiki-devs] [Proposal] New GWT-based WYSIWYG editor

by Marius Dumitru Florea

Hi all, I've just joined the XWiki dev community today and this is my first post. As Vincent told you, from now on I'll be working on the new GWT-based WYSIWYG editor. I'll do my best, but I need your help on this. In the next few days I'll be reading the documentation for the new architecture, including WikiModel and GWT. After that, I'll post my ideas so you can make comments. Thanks everyone, -Marius

17 years, 2 months

Re: [xwiki-devs] [xwiki-dev] [Proposal] Document comments should not create new versions

by Vincent Massol

(resending - I sent it on the 6th to the wrong OW dev list...) > If we don't increase version then how is it going to appear in the > history view. Namely, how would you see that a comment has been added? > > Of course we would still need to send notifications even when > comments are added. > > This is a general question about objects attached to a document. As > of now I'm not sure we should treat some objects differently than > others. > > Just to step back and play the devil, why is it bad that document > version is increased when comments are added? > > Thanks > -Vincent > > On Aug 24, 2007, at 4:44 PM, Sergiu Dumitriu wrote: > >> Hi, >> >> This is more a matter of opinions. Should a comment increase the >> version of a document? I'd say yes, but the view of simple users is >> that a comment should not affect the document, as it is something >> describing the document, not belonging to the document. So we should >> have a parameter that configures this. >> >> WDYT? >> Sergiu >> -- >> http://purl.org/net/sergiu

17 years, 2 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs