xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Re: [xwiki-devs] [xwiki-notifications] r13414 - in sandbox/xwiki-webdav/src/main: java/com/xpn/xwiki/plugin/webdav/resources java/com/xpn/xwiki/plugin/webdav/resources/views java/com/xpn/xwiki/plugin/webdav/utils resources resources/META-INF resource

by Asiri Rathnayake

Hi Sergiu, On Fri, Oct 10, 2008 at 6:20 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > asiri (SVN) wrote: > > Modified: > sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java > > =================================================================== > > --- > sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java > 2008-10-08 11:28:58 UTC (rev 13413) > > +++ > sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java > 2008-10-08 12:12:14 UTC (rev 13414) > > @@ -9,6 +9,8 @@ > > import org.apache.jackrabbit.webdav.DavResourceLocator; > > import org.apache.jackrabbit.webdav.DavSession; > > import org.apache.jackrabbit.webdav.lock.LockManager; > > +import org.xwiki.component.manager.ComponentManager; > > +import org.xwiki.component.phase.Composable; > > > > import com.xpn.xwiki.XWikiContext; > > > > @@ -18,9 +20,14 @@ > > * > > * @version $Id$ > > */ > > -public interface XWikiDavResource extends DavResource > > +public interface XWikiDavResource extends DavResource, Composable > > { > > /** > > + * This component's role, used when code needs to look it up. > > + */ > > + String ROLE = XWikiDavResource.class.getName(); > > + > > + /** > > * Initializes this resource with common attributes inherited from > the parent. > > * > > * @param parent Parent resource. > > @@ -72,6 +79,11 @@ > > XWikiContext getXwikiContext(); > > > > /** > > + * @return The {@link ComponentManager} used to lookup components. > > + */ > > + ComponentManager getComponentManager(); > > + > > + /** > > * @return The {@link LockManager} associated with this request > (global). > > */ > > LockManager getLockManager(); > > I don't like this... a component interface should not expose the > component manager, which is supposed to be used in implementations. Please: > - remove the Composable from the interface > - add it to AbstractXWikiDavResource, if needed > - move the getComponentManager there, too, if you must > > I'm not sure you need the component manager inside all DAV resources. As > I see in the code, you only need it in the Root view, so you should only > declare that XWikiRootDavView implements Composable. > > > FYI, the XWiki helper interfaces (Composable, LogEnabled, Initializable) > are supposed to be used by implementations, not by other interfaces. Working on it. Thanks. - Asiri > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

16 years, 4 months

[xwiki-devs] [xwiki-notifications] r13428 - in sandbox/xwiki-webdav/src: main/java/com/xpn/xwiki/plugin/webdav/resources/views main/java/com/xpn/xwiki/plugin/webdav/resources/views/pages test/java/com/xpn/xwiki/plugin/webdav/tests

by Asiri Rathnayake

---------- Forwarded message ---------- From: Asiri Rathnayake <asiri.rathnayake(a)gmail.com> Date: Thu, Oct 9, 2008 at 2:09 PM Subject: Re: [xwiki-notifications] r13428 - in sandbox/xwiki-webdav/src: main/java/com/xpn/xwiki/plugin/webdav/resources/views main/java/com/xpn/xwiki/plugin/webdav/resources/views/pages test/java/com/xpn/xwiki/plugin/webdav/tests To: XWiki Notifications <notifications(a)xwiki.org> Hi Vincent, Sergiu and all, I will try to explain the need to componetize xwiki-webdav. May be we shouldn't componetize xwiki-webdav after all ;) Following is the way we lookup for a base-view (a particular view of an xwiki-repository). Basically, when a request comes for a particular url, we take the corresponding segment of the url (nextToken here), append "-baseview" and lookup for a component with that ROLE_HINT. If found, we'll handover the job to that component. > + XWikiDavResource resource = null; > + try { > + resource = > + (XWikiDavResource) getComponentManager() > + .lookup(ROLE, nextToken + "-baseview"); > + resource.init(this, nextToken, "/" + nextToken); > + stack.push(resource); > + resource.decode(stack, tokens, next + 1); > + } catch (ComponentLookupException e) { > + throw new > DavException(DavServletResponse.SC_INTERNAL_SERVER_ERROR, e); > Bellow is where we list the set of possible views. for this i need to filter out only those views which has the "-baseview" id appended to their role hint. This is why i added the getRoleHint() method into the component interface. The use of this approach is, if someone need to add a new view, he simply have to extend the XWikiDavResource interface and have the ROLE_HINT ending like "-baseview", nothing else. The other approach is to manually load each base view using lookup("role", "role-hint") but in this case, the developer of the new view will have to change the RootView's code to load his view along with the rest of base views. > > + List<XWikiDavResource> viewsList = > getComponentManager().lookupList(ROLE); > + for (XWikiDavResource view : viewsList) { > + String componentHint = view.getRoleHint(); > + int dash = componentHint.lastIndexOf('-'); > + if (componentHint.endsWith("-baseview")) { > + String name = componentHint.substring(0, dash); > + view.init(this, name, "/" + name); > + children.add(view); > + } > + } > + } catch (ComponentLookupException e) { > + LOG.error("Unexpected Error : ", e); > May be this is a wrong approach. And yes, XWikiDavResource is not a business interface. But I think this increases the extensibility / flexibility of xwiki-webdav. To add a new view, (as i said before) extend XWikiDavResourve and end your ROLE_HINT with "-baseview". To remove an existing view, simply remove the "-baseview" part from your components.xml configuration file, that's it. I would like to know your thoughts. And i can revert these changes if necessary. Thanks. - Asiri

16 years, 4 months

[xwiki-devs] XWiki as ACEGI provider?

by Paul Libbrecht

Has anyone worked on XWiki serving the role of an ACEGI provider? (identity managed by XWiki but shared to other, in VMs, web-apps) thanks in advance paul

16 years, 4 months

by Sergiu Dumitriu

asiri (SVN) wrote: > Modified: sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java > =================================================================== > --- sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java 2008-10-08 11:28:58 UTC (rev 13413) > +++ sandbox/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/XWikiDavResource.java 2008-10-08 12:12:14 UTC (rev 13414) > @@ -9,6 +9,8 @@ > import org.apache.jackrabbit.webdav.DavResourceLocator; > import org.apache.jackrabbit.webdav.DavSession; > import org.apache.jackrabbit.webdav.lock.LockManager; > +import org.xwiki.component.manager.ComponentManager; > +import org.xwiki.component.phase.Composable; > > import com.xpn.xwiki.XWikiContext; > > @@ -18,9 +20,14 @@ > * > * @version $Id$ > */ > -public interface XWikiDavResource extends DavResource > +public interface XWikiDavResource extends DavResource, Composable > { > /** > + * This component's role, used when code needs to look it up. > + */ > + String ROLE = XWikiDavResource.class.getName(); > + > + /** > * Initializes this resource with common attributes inherited from the parent. > * > * @param parent Parent resource. > @@ -72,6 +79,11 @@ > XWikiContext getXwikiContext(); > > /** > + * @return The {@link ComponentManager} used to lookup components. > + */ > + ComponentManager getComponentManager(); > + > + /** > * @return The {@link LockManager} associated with this request (global). > */ > LockManager getLockManager(); I don't like this... a component interface should not expose the component manager, which is supposed to be used in implementations. Please: - remove the Composable from the interface - add it to AbstractXWikiDavResource, if needed - move the getComponentManager there, too, if you must I'm not sure you need the component manager inside all DAV resources. As I see in the code, you only need it in the Root view, so you should only declare that XWikiRootDavView implements Composable. FYI, the XWiki helper interfaces (Composable, LogEnabled, Initializable) are supposed to be used by implementations, not by other interfaces. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 4 months

[xwiki-devs] [Idea] Providing a production level packaging solution with Jetty+Derby

by Vincent Massol

Hi, I was wondering today if we could provide a production quality XE packaging. Here's what would be my combo: * Jetty 6 or 7 * Latest Derby (aka JavaDB - which is included in JDK 1.6 BTW) in embedded mode See http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-45170… for performance stats * Java Service Wrapper See http://wrapper.tanukisoftware.org/doc/english/integrate.html The nice thing with the wrapper is that it can also monitor the JVM and restart it if hung or not responding, in addition to restarting the service when the machine is rebooted of course. I'm confident that we could offer a base packaging that would work well for relatively large usages of XE and that is still small and all- preconfigured. Basically I think we could replace our current combo of Jetty 5.x + HSQLDB with this new combo and still get the best of both worlds: * simple packaging * production level quality Whereas our current standalone packaging is not production ready and is just for getting started with XWiki. WDYT? Thanks -Vincent

16 years, 4 months

Re: [xwiki-devs] [xwiki-users] Loginsubmit

by Jean-Vincent Drean

On Wed, Sep 24, 2008 at 4:44 PM, Spinring <bi2607(a)fh-weihenstephan.de> wrote: > > Hello, > > I am trying to change the registration page, so that it redirects to the > pevious page after you have registered (like after you have logged in) > > I know, that login.vm and registerinline.vm are called in global.vm. My > first try was to add xredirect=$xwiki.getURLEncoded($logredir) to the > $regurl, but it did work. The register action takes into account the xredirect and do it immediatly. [1] Anyway you could add redirect=$xwiki.getURLEncoded($logredir) to the $regurl (global.vm) And apply this to registerinline.vm #elseif($reg) + #if($request.redirect) + $response.sendRedirect($request.redirect) + #end #set($xwname = "XWiki.${request.xwikiname}") #info("$msg.get('core.register.successful', [$xwiki.getUserName($xwname), $request.xwikiname])") #end Anyway I'm not sure that you'll get the expected behavior since the user will be correctly redirected .. without being logged in. To log the user automatically after sign up (+ redirection) you can apply the following patch to registerinline.vm (replace the one above) : #elseif($reg) + #if($request.redirect) + #set ($xredirect = $xwiki.getURL("XWiki.XWikiLogin", "loginsubmit", "j_username=$!request.xwikiname&j_password=$!request.register_password&xredirect=$!request.redirect")) + $response.sendRedirect($xredirect) + #end #set($xwname = "XWiki.${request.xwikiname}") #info("$msg.get('core.register.successful', [$xwiki.getUserName($xwname), $request.xwikiname])") #end 1) While we are at it, WWYT about adding this in XE 1.7, xwiki devs ? Is it bad to have the password sent over the network once again ? 2) In this case is there a reason to keep the sendRedirect call in RegisterAction (see [1]) ? Thanks, JV.

16 years, 4 months

Re: [xwiki-devs] [xwiki-notifications] r13383 - platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/parser

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-10-07 20:01:06 +0200 (Tue, 07 Oct 2008) > New Revision: 13383 > > Modified: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/parser/SyntaxType.java > Log: > XWIKI-2744: Can't add a Parser component for an unknown syntax > * add equals and hashCode methods > Since these methods do nothing but the default, why do we need to override them? The inherited methods should be enough, no? Anyway, I'd rather have a real implementation, since we can't be sure that everybody will create syntaxes using the factory method. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 4 months

Re: [xwiki-devs] [xwiki-notifications] r13381 - platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/renderer

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-10-07 19:24:57 +0200 (Tue, 07 Oct 2008) > New Revision: 13381 > > Added: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/renderer/XHTMLWikiPrinter.java > Removed: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/renderer/AbstractXMLRenderer.java > Modified: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/renderer/XHTMLRenderer.java > Log: > * makes AbstractXMLRenderer a XHTMLWikiPrinter tool > I don't quite agree with this... The class is about XML printing, yet it is named XHTML. The methods are all about pure XML: printXMLStartElement, printXMLEndElement, createAttributes... And I'd like to keep it that way, if we don't need something HTML specific in it, just in case we'll need a different renderer (DocBook? the dead WML?). -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 4 months

[xwiki-devs] [Proposal] Rendering Link Syntax Take 2

by Vincent Massol

Hi devs, Sorry for the numerous mails on this topic. I've been struggling a bit in choosing the best solution with the caveats brought by wikimodel. So here's my latest proposal that replaces all previous ones on the link topic: 1) General link syntax: [[label>>reference]] or [[label||reference]] Note1: I've removed the need for parameters, see below. Note2: I'm suggesting double character separators since if we allow wiki syntax in link labels we need to easily differentiate the separator from a character typed in the label. Same reason why we doubled [[ ]], **, //, etc. characters. We could still use single characters (open question, I'm not sure about double chars) since people are not meant to write tons of text in link labels. OTOH it's consistent with our usage of double chars everywhere else (but it breaks current habits of the single char for links). 2) Links with parameters: (% param1=value1 paramN=valueN %)[[label>>reference]] 3) Links with wiki syntax for the label: [[**bold** link>>reference]] [[{{velocity}}...{{/velocity}}>>reference]] [[{{image:...}}>>reference]] <-- image link <OT> Note: For the image link we'll still need to decide if we want a macro for inserting an image or use wiki syntax but that's a topic that is now dissociated from the link topic: [[{{image:my.png}}>>reference]] or [[image:my.png>>reference </OT> Last for those wondering, I've found a solution to make this work with wikimodel and I've discovered Doxia supported wiki syntax in link labels, hence why I'm resurrecting the idea of having wiki syntax in links which is a way superior solution. Thanks -Vincent

16 years, 4 months

Re: [xwiki-devs] Things change

by Anca Paula Luca

Evelina Slatineanu wrote: > Hello all, > > > > This time I will "bother" you with a different type of mail, not the usual > bugs and fixes issues that come on dev mailing lists. > > > > First, let me say that so far it was nice to be part of the XWiki Team. And > many thanks to those who worked with me and helped me when I couldn't do it > by myself. Here, first in the list goes Sergiu Dumitriu, who was helped me > more than anyone else throughout the time. Also, thanks to Marta, Jerome, > JV, Laurent and the whole Iasi Team. I hope I'm not forgetting anyone. > > It has been a nice opportunity to work with you guys. > It's the same here, even if it might not have always felt like this. > > > However, time has come to say goodbye to all of you and continue my journey > with the next step in my professional life. I am going to pursue the goal of > becoming a good java programmer and even if XWiki could provide me with an > environment for doing this, I feel I need something more than that. There > are already plenty of intelligent and motivated people who do this very well > in XWiki and I would always be in their shadow. I feel I need to do this by > myself. > Since I think I know what it means and I'm enjoying it most of the seconds of everyday, I hope this decision is a step towards you finding the thing you like to do and which will make you happy (professionally speaking). I won't hide how disturbing it is to see people who have been here (in Iasi) from the very beginning leave. > > > So, I can only wish everyone good luck and success in whatever is that > everyone is doing. I am sure that only a bright and successful future awaits > XWiki. I can only wish it the best. > > > > Thank you very much for working with me. > +1 > > > Evelina Vrabie > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

16 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs