xwiki-devs May 2010

xwiki-devs@xwiki.org

30 participants
85 discussions

[xwiki-devs] New search admin UI and icon

by Thomas Mortagne

Hi devs, I committed the new search admin UI and fixed some issuse, should work well now. Some notes: * the actual configuration is put in a document automatically created if it does not exist so that you can upgrade the whole app without having to worry about what you will overwrite * it's using Configurable system but just to be "injected" as admin app, would be nice to be able to have some reusable code when you need custom UI but still we some standard configuration style in the middle of it * there is a new central search page (Main.Search) which include the proper engine search page depending of the configuration Missing things are: * an nice icon: would be cool to have someone else than me on that * rename "web" into "database", i just moved the page yet but "web" is not very nice and i need to change it. I'm just a bit worried about backward compatibility, i think i will create a DatabaseSearch page and redirect WebSearch to Search probably to make old apps use the right default search engine instead of the old hardcoded websearch default page * make number of indexing element refresh automatically using ajax: i'm working on something else right and it's not urgent but i will take care of it (I'm not begging for it if someone want to take it ;)) * write documentation for it in xwiki.org (especially about how to use indexing UI), about that do we have some clean way to put documentation tooltips or something nice to explain to the use what he can put in the fields and how it's working ? Would be cool that some people review it (pretty sure there is typos I did not seen, there is always...). Thanks, -- Thomas Mortagne

14 years, 7 months

Re: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table

by Jerome Velociter

----- "Denis Gervalle" <dgl(a)softec.lu> wrote: > On Thu, May 20, 2010 at 19:23, Vincent Massol <vincent(a)massol.net> > wrote: > > > > > On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote: > > > > > Author: dgervalle > > > Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010) > > > New Revision: 28950 > > > > > > Modified: > > > > > > platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > > > Log: > > > XWIKI-5212 - Livetable filter serialization does not properly > support > > multi-valued form elements > > > Merge from trunk r28947 > > > > Do we have a test for this? How do we unit-test UI components? > > > > This would be nice to have. Building proper tests is not so easy, this > could > be very long to setup, since you need to test in several browsers and > you > need full AJAX interaction. That's basically what we do with Selenium, except that we test the integration of the features in the wiki, not the atomic behaviors of the components. There isn't really an alternative to launching a browser for testing our JS components, since most if not all of them heavily rely on a DOM, so just a JS runtime will not be enough. We could envisage a JS unit-testing system like this : - Write tests in .js files, using JSUnit or any other unit testing JS framework (http://ejohn.org/blog/which-unit-testing-framework/) - Slurp the tests in a XAR using a maven plugin - Execute the tests inside XE, using Selenium wdyt ? Jerome. > I am not used to such automated testing, > but I > am not sure the investment is worse the improvement we could get from > them. > > On the other side, I use livetables JS heavily, so you could be > assured that > my fixes/improvements are either well tested or will be fixed ASAP > since all > changes I introduce is already in production. We also usually test > them on > all supported browsers, and at least on IE6/7/8, FF3 (Win/Mac), > Safari4 > (Mac) and Chrome (Mac) > FYI, I found this one when we have introduced the usage of hashes to > provide > "Back to the list" links. I will soon commit an improvement supporting > the > page size in hash as well, so you can really get very precise "back to > the > list" return links. > > Denis > > Thanks > > -Vincent > > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

14 years, 7 months

[xwiki-devs] 答复: Embed xwiki to existing project

by 靳雄飞

XWiki support XMP-RPC and REST, So I am wondering if one can integrate third-party-app with XWiki through XML-RPC. That is, use XWiki as a page store/search/versioning platform, and third-party-app response for page editing and display. If there's a easy way to embed XWiki's editor and render engine into my application, the integration work will be very easy I think. I'm not sure if this can be achieved, I am studying. > >Hi... Good to know there are people with common interest in embedding xwiki >to existing project. > >Here is my confusion. Please comment if you have idea on this. >I have my J2EE project. It uses JSF, Spring and Hibernate. So I have my own >hibernate.cfg.xml and web.xml and other config files. >Now, I'm trying to add xwiki as a module to my project. Since Xwiki uses >Struts and Hibernate, it also has its own hibernate.cfg.xml and web.xml >files. >How do I integrate these two now? >Can I have both of these in my project and move on? > >If I am able to work it out, I think I can move forward. I just learnt the >way how we can delegate the struts action management to the spring >framework. > >Regards, >Manish >-- >View this message in context: http://xwiki.475771.n2.nabble.com/Embed-xwiki-to-existing-project-tp5070278p 5081734.html >Sent from the XWiki- Dev mailing list archive at Nabble.com. >_______________________________________________ >devs mailing list >devs(a)xwiki.org >http://lists.xwiki.org/mailman/listinfo/devs

14 years, 7 months

[xwiki-devs] Extension Manager - First Objective

by Vincent Massol

Hi devs, Just to keep you abreast, Thomas and I are working on the following use case POC fpr midle of next week (hopefully): - Ability to install the JRuby macro from our XWiki Remote repo in a running XE (note that installing this macro is interesting since it has dependencies on another artifact (jruby)). For this we'll develop: - A xwiki-extension-manager module (in sandbox for now). The code will use Maven classes underneath to download the jruby macro + its dependencies to a local repo - A xwiki-extension-manager application XAR (in sandbox for now). It'll be supra simple UI with just a text field where to specify the groupId + artifactId + version - We'll also update the xwiki-classloader module to allow unloading of JARs from a URL Classloader. Thanks -Vincent

14 years, 7 months

[xwiki-devs] [Discussion] OSGi POC result and base for the Extension Manager

by Vincent Massol

Hi devs, I've explored enough of OSGi to get a handle of how it works and what it would mean to use it for XWiki as the basis for our Extension Manager (Thomas helped me with this too). The executive summary is that I don't think we need to use OSGi right now for the Extension Manager and we can defer its usage for later. Let me start by listing what would OSGi bring for XWiki: 1) Known framework with good documentation, books, etc 2) Users would be able to write extensions using OSGi programming model (without using XWiki's programming model), this also means the ability to reuse OSGi bundles inside XWiki 3) ClassLoader isolation and thus ability to have several versions of classes 4) OBR (Bundle Repository) for downloading and installing remote jars Now here are the problems found with OSGi so far: A) Impedance mismatch with the webapp/WAR model (classloader and visibility issues). Two examples: - it would mean having a special directory somewhere, where to put the bundles, and this means not going through the standard WAR deployment process. - if we want to keep WEB-INF/lib in order to have a standard WAR deployment then it would mean keeping for ex the core jars in WEB-INF/lib and using OSGi only for extensions. However doing this is not really possible since it would mean extension (OSGi bundles) would have Imports on core classes but this won't work since core classes won't be OSGi bundles B) In practice it's very hard to use OSGi with only a part of the modules being OSGi bundles and another part being standard external libraries. Everything must be OSGified for it to work well. In addition we might want not need the features listed above: 1) Not really needed especially since we have the XWiki programming model that we don't want to loose right now 2) is a nice to have but not a requirement for the Extension Manager 3) in practice it's going to be very hard to support multiple versions of classes. Imagine for example an application A which is providing a macro in a wiki page. Application B requires version 1.0 of A and application C requires version 2.0 of A. How do we support that? OSGi won't help here since this is about wiki pages. It's only helping for jars. The jar isolation could also easily be implemented using a custom URL classloader without too much problem IMO, but I'm inclined to say that we don't need to support multiple versions in a first version of the Extension Manager. 4) We can easily use the Maven 3 Embedder to download and install maven artifacts into a local repository. This is convenient since we already deploy our applications/modules to a maven repository. Note that the only "difficult" part here might be searching into a remote repository; I don't know if a maven api exists for this (but probably). In the worst of cases we could use the Nexus REST API to provide this feature for now. And here's what I think we should do right now: i) focus on the 2 features we need for the Extension Manager: -- ability to install an application containing not only wiki pages but also jars -- ability to install an application from a remote repository ii) then once i) is done focus on the upgrade part of the extension manager Implementation note: - To implement i) we can do this easily I believe using a custom URL ClassLoader (we already have one btw used in the script macro) that we pass to the Component Annotation Loader when a new JAR is installed (in order to register the components in that jar) + set that custom URL ClassLoader as the new thread context classloader (for code that would use the thread context classloader to load classes). WDYT? Thanks -Vincent PS: I'd be interested to hear from OSGi experts what they have to say about this since I'm an OSGi newbie and there might be stuff I have not seen/realized. PPS: I'm just realizing that the proposal in this mail is close to Pomegranate's idea: http://www.caucho.com/projects/pomegranate/

14 years, 7 months

[xwiki-devs] YourKit Java Profiler 9.0 Released

by Vincent Massol

See http://bit.ly/b1iPgf Note that all xwiki committers have a Yourkit license key available to them on dev.xwiki.org (tools page). Thanks -Vincent

14 years, 7 months

[xwiki-devs] Fwd: [ANNOUNCE] Apache VelocityTools 2.0 release

by Vincent Massol

Possible candidate for upgrade in XWiki too. Thanks -Vincent Begin forwarded message: > From: Nathan Bubna <nbubna(a)apache.org> > Date: May 19, 2010 2:56:21 AM GMT+02:00 > To: Velocity Users List <user(a)velocity.apache.org>, Velocity Developers List <dev(a)velocity.apache.org>, private <private(a)velocity.apache.org>, announce(a)apache.org > Subject: [ANNOUNCE] Apache VelocityTools 2.0 release > > The Apache Velocity project is pleased to announce the release of > VelocityTools 2.0. > > Downloads are available here: > http://velocity.apache.org/download.cgi > > This should be useable as a drop in replacement for Tools 2.0-beta4 or > Tools 1.4, with a few minor exceptions. The 2.x series of > VelocityTools requires Velocity 1.5+ and JDK 1.5+. > > For those new to Tools 2, here's an overview of the work done since 1.4: > * More convention over configuration and smart defaults > * New configuration formats (more concise/flexible/powerful xml, > properties, java) > * Provision of default and auto-loaded configurations > * Entirely new core infrastructure (lazy-loading tools, easier > access, standalone support etc) > * Added VelocityViewTag for JSP integration > * Added DisplayTool, ConversionTool, ClassTool, LoopTool, > FieldTool, a generic version of LinkTool and more > * Refactored and enhanced a number of existing tools > * Improved documentation > * Deprecated many outdated things > * Legacy support for almost all Tools 1.4 configurations and extensions > * Better integration of $application, $session and $request scope > control objects > * and lots more... > > For those following the betas, here's the notable changes since 2.0-beta4: > * Added a 'readOnly' config option to allow write operations on > ValueParser and ParameterTool (when set to false) > * Added a beta-quality UiDependencyTool (included in > velocity-view, but not in default tools.xml) > * Added an alpha-quality MarkupTool (included in generic tools, > but not in default tools.xml) > * Fixed (as much as possible) some significant last-iteration > LoopTool problems, and added a $loop.this property to serve as a more > reliable workaround in nested loops. See > https://issues.apache.org/jira/browse/VELTOOLS-124 > * VelocityLayoutServlet now checks request attributes for > non-default layouts. > * The velocity-view.tld is now valid. > * VelocityView[Servlet] has improved exception and http management > (particularly for ResourceNotFoundExceptions). > * Miscellaneous documentation and build.xml improvements > > The Velocity developers are very interested in all feedback regarding > Tools 2.0, especially regarding backwards compatibility with apps > designed for Tools 1.4 or earlier. We aim to enable a smooth, > incremental transition for developers and their applications.

14 years, 7 months

[xwiki-devs] Fwd: [ANNOUNCE] Apache Velocity Engine 1.6.4

by Vincent Massol

Seems there are bug fixes that could be important to us: - Fix bug in #parse that threw an NPE when IncludeEventHandler returned null and inline macros are kept local. Fixes VELOCITY-717. Thanks to Jarkko Viinamaki. nbubna - Fix double-checked locking in RuntimeInstance's optional lazy-init for Java 1.5+. Users of older JREs in multi-threaded environments MUST manually call init() on any thread-shared Velocity singleton or VelocityEngine instances to avoid race conditions. New auto-init feature is only supported on Java 1.5+. Fixes VELOCITY-750. nbubna - Fix 100% CPU loop hang under simultaneous HashMap calls in ClassMap due to classic bug in Sun's implementation. Now uses ConcurrentHashMap when available and Hashtable otherwise. Fixes VELOCITY-718. Thanks -Vincent Begin forwarded message: > From: Nathan Bubna <nbubna(a)apache.org> > Date: May 19, 2010 2:55:58 AM GMT+02:00 > To: Velocity Developers List <dev(a)velocity.apache.org>, Velocity Users List <user(a)velocity.apache.org>, announce(a)apache.org > Subject: [ANNOUNCE] Apache Velocity Engine 1.6.4 > > The Apache Velocity Team announces the availability of the of Apache > Velocity Engine 1.6.4. This is only a bugfix release and contains no > new features. We recommend all 1.6.x users upgrade to this release. > > The change log is here: > http://velocity.apache.org/engine/releases/velocity-1.6.4/changes-report.ht… > > Apache Velocity 1.6.4 can be downloaded here: > http://velocity.apache.org/download.cgi > > Documentation for Engine1.6.4 can be found here: > http://velocity.apache.org/engine/releases/velocity-1.6.4/ > > For the Apache Velocity Team, > > Nathan Bubna

14 years, 7 months

Re: [xwiki-devs] Embed xwiki to existing project

by 靳雄飞

Hi, I'm also very interested in this topic, because I am planning to start a integration soon . I'm reading XWiki developer guide these days, what I am still not very clear or worry about are: 1. The memory consumption seems rather high. 2. I am trying to figure out how to create wiki-pages use java code and redirect to my own page for edit, my own page merge wiki-page edit and my app related data, such as use's activity stream or friend information. 3. How to implement single login, have some clue, but not very clear. but I believe it's only a matter of time. What I'm trying to do, is a site for collaborative study. XWiki will be used for study material collecting, based on topics and study plan. My own application focused on study plan management and study process management. Eager to see Andreas's site online!. -----邮件原件----- 发件人: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] 代表 Andreas Hahn 发送时间: 2010年5月18日 23:46 收件人: XWiki Developers 主题: Re: [xwiki-devs] Embed xwiki to existing project Hi, I'm trying that also and I'm very interested in the topic. I'm trying to 'merge' a given J2EE app with XWiki to enhance the existing app with XWikis community features. (Comments, annotations, documentation, help, e.t.c.). So far I've managed to make them both running under a common domain name with some tweaking of Apache mod-proxy and unifying the (example) urls http://example.com/app/here_goes_my_java_app <http://mydomain.com/app/here_goes_my_java_app> http://example.com/docs/heres_the_wiki_stuff <http://mydomain.com/docs/heres_the_wiki_stuff> Apache Httpd (mod_proxy) is configured as a seperate service to run upfront of the servelet container (Tomcat). This took some effort as I had to learn a lot about the Apache mod_proxy stuff but its not XWiki related so far. As both apps have quite a different look and feel I've further been struggling with adapting XWikis skins to the look and feel of my app - this turned out be be less work than I thought just by adding my apps stylesheet WebPreferences and commenting out a lot of the existing styles with 'display: none'. Both apps have their own db and the next step is to achieve single logon - I haven't yet managed that but plans are to make XWiki looking up for users in the my apps database. Currently I'm having trouble with the anonymous commenting feature of xwiki, it always rejects all input. Maybe this has to do with my setup but all other stuff works pretty well. Is anybody aware of a public xwiki with enabled anon commenting feature ? As its sort of fun and part time project things may take a while ... If you are interested please drop me a note and I'll send a mail once it is online ... Have fun Andreas xManish schrieb: > Has anybody embedded xwiki into their existing project? I am looking to embed > wiki engine to my existing project. If anybody has done that, would you > share your experience in doing so. Like how you started it. What are > possible options for it. > > Thankyou in advance, > Manish > _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

14 years, 7 months

[xwiki-devs] Embed xwiki to existing project

by xManish

Has anybody embedded xwiki into their existing project? I am looking to embed wiki engine to my existing project. If anybody has done that, would you share your experience in doing so. Like how you started it. What are possible options for it. Thankyou in advance, Manish -- View this message in context: http://xwiki.475771.n2.nabble.com/Embed-xwiki-to-existing-project-tp5070278… Sent from the XWiki- Dev mailing list archive at Nabble.com.

14 years, 7 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs May 2010