xwiki-devs May 2008

xwiki-devs@xwiki.org

53 participants
158 discussions

by rssh

Good day. Such question: is something was changed in xwiki build procedure ? Now, when I want to build xwiki-product-enterprise I receive [rssh@a22 xwiki-product-enterprise]$ mvn install [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Failed to resolve artifact. Missing: ---------- 1) com.xpn.xwiki.platform.tools:xwiki-xar-handlers:jar:1.9-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.xpn.xwiki.platform.tools -DartifactId=xwiki-xar-handlers \ -Dversion=1.9-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) com.xpn.xwiki.products:xwiki-enterprise-parent:pom:1.5-SNAPSHOT 2) com.xpn.xwiki.platform.tools:xwiki-xar-handlers:jar:1.9-SNAPSHOT ---------- 1 required artifact is missing. for artifact: com.xpn.xwiki.products:xwiki-enterprise-parent:pom:1.5-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) -- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua

16 years, 3 months

Re: [xwiki-devs] Tutorial to write validations and tooltips in forms

by Niels Mayer

Regarding the very helpful tutorial at XWiki - DevGuide - Creating a form with validation and tooltips<http://platform.xwiki.org/xwiki/bin/view/DevGuide/Creating+a+form+with+vali…>I've noticed a situation where it was expecting an int and had an error if it was given text instead: http://localhost:8080xwiki/bin/view/ValidationSample/ -> I fill In form with first_name: jar last_name: jar age: binks emal: binks(a)jarjar.com usphone: 123-456-7890 text: poipoipoipoipoi -> click create, which brings me to http://localhost:8080/xwiki/bin/view/ValidationSample/CreateDoc : CreateDoc ________________________________ Error number 4001 in 4: Error while parsing velocity page ValidationSample.CreateDoc Wrapped Exception: Invocation of method 'updateObjectFromRequest' in class com.xpn.xwiki.api.Document threw exception java.lang.NumberFormatException: For input string: "binks" @ ValidationSample.CreateDoc6,20? How to trap this type exception in the validation code itself? Input type-checking is why validation is needed in the first place. -- Niels Mayer ( http://http://www.curriki.org/xwiki/bin/view/XWiki/NielsMayer) Curriki: The Global Education & Learning Community

16 years, 3 months

[xwiki-devs] Bulletin Board Application - How to post?

by shivshan

Hi I have installed the bulletin board application (version BulletinBoardApplication2.xar) on XE 1.4. I can see the admin pages and also added the panels. However there is no way, at least for me, to post to a bulletin board. There is a PostClass but no associated ClassSheet and ClassTemplate in the xar. Am i missing something? Regards, Shiva -- View this message in context: http://www.nabble.com/Bulletin-Board-Application---How-to-post--tp17359096p… Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years, 3 months

[xwiki-devs] Exception When changing skins

by marlon hendred

Hi, When I try to change the skin with the admin gui to albatross i get the following stack trace: Error number 3201 in 3: Exception while saving document XWiki.XWikiPreferences Wrapped Exception: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xpn.xwiki.objects.LargeStringProperty# ] com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while saving document XWiki.XWikiPreferences Wrapped Exception: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xpn.xwiki.objects.LargeStringProperty# ] at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:573) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:97) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:91) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1130) at com.xpn.xwiki.web.SaveAction.save(SaveAction.java:130) at com.xpn.xwiki.web.SaveAction.action(SaveAction.java:140) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:204) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Wrapped Exception: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xpn.xwiki.objects.LargeStringProperty# ] at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1765) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2407) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at com.xpn.xwiki.store.XWikiHibernateBaseStore.endTransaction(XWikiHibernateBaseStore.java:816) at com.xpn.xwiki.store.XWikiHibernateBaseStore.endTransaction(XWikiHibernateBaseStore.java:787) at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:563) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:97) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:91) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1130) at com.xpn.xwiki.web.SaveAction.save(SaveAction.java:130) at com.xpn.xwiki.web.SaveAction.action(SaveAction.java:140) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:204) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684 at java.lang.Thread.run(Thread.java:595) Any Ideas? It swithes the skin, but the next time i login its back on the toucan skin. Also The reason why Im using the old albatross skin is because then toucan skin doesn't display any users...any ideas about that too? Thanks in advance! -Marlon

16 years, 4 months

[xwiki-devs] searchDocuments exception

by Glenn Everitt

I looked at the FAQ example and am trying to write a query to get all of the blog entries for a specific author here is the script: #set ($sql = ", from BaseObject as obj where doc.fullName = obj.name and obj.className = 'XWiki.ArticleClass' and doc.author = 'XWiki.GEVERITT'") #set ($start = 0) #set ($nb = 50) #set ($collect = $xwiki.searchDocuments($sql , $nb , $start)) # $collect.size() #foreach ($item in $collect) #if ($xwiki.hasAccessLevel("view", "${context.database}:${item}")) #set($bentrydoc = $xwiki.getDocument($item)) #set($date = $xwiki.formatDate($bentrydoc.date,"MMMM dd, yyyy HH:mm")) #<p>$bentrydoc.name $date</p> #end #end I see this exception Error number 4001 in 4: Error while parsing velocity page COE.Blog_GEVERITT Wrapped Exception: Invocation of method 'searchDocuments' in class com.xpn.xwiki.api.XWiki threw exception com.xpn.xwiki.XWikiException: Error number 3223 in 3: Exception while searching documents with SQL web, doc.name from XWiki Document as doc , from Base Object as obj where doc.full Name = obj.name and obj.class Name = 'XWiki.Article Class' and doc.author = 'XWiki.GEVERITT'? Wrapped Exception: unexpected token: from near line 1, column 81 web, doc.name from com.xpn.xwiki.doc.XWiki Document as doc , from com.xpn.xwiki.objects.Base Object as obj where doc.full Name = obj.name and obj.class Name = 'XWiki.Article Class' and doc.author = 'XWiki.GEVERITT'? @ COE.Blog_GEVERITT4,25? and then see this which looks like the query that was executed. What looks odd is that doc.author has the bread crumb trail in it "User Blogs > Blog_GEVERITT" instead of just "GEVERITT" select distinct doc.web, doc.name from XWikiDocument as doc , from BaseObject as obj where doc.fullName = obj.name and obj.className = 'XWiki.ArticleClass' and doc.author = 'XWiki: User Blogs > Blog_GEVERITT > GEVERITT' Any idea what the problem is? Any help or suggestions on debugging it would be appreciated. I am using XWiki 1.3.2, Oracle 10, Tomcat 5.5 Thanks Glenn Everitt -- View this message in context: http://www.nabble.com/searchDocuments-exception-tp17339532p17339532.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years, 4 months

[xwiki-devs] SourceKibitzer EyeQ reports

by Vincent Massol

Hi everyone, SourceKibitzer is offering us some activity reports based on our SVN activity. I've created a page here to host those reports: http://dev.xwiki.org/xwiki/bin/view/Community/EyeQReports They provide information such as: * contribution size * activity * unique know how (ie code only you have modified) * shared know how * code complexity * % of comments Make sure you read the caveats on the page to understand the reports. Right now I find the contribution size metric quite misleading. However SK is working on improving it. Thanks -Vincent

16 years, 4 months

Re: [xwiki-devs] FW: New Admin Design direction

by Vincent Massol

On May 20, 2008, at 11:14 AM, Evelina Slatineanu wrote: > One proposal is to make the panels part of XE (not application > anymore, > since they have dependencies in XE) and move the PanelWizard in the > Administration application (since this one will contain PanelWizard > for both > wiki and space level, so there is no point for the PanelWizard to > exist > outside administration). WDYT? I'm not sure. I'd prefer we go the opposite way. There's nothing IMO that forces us to make Panels compulsory and I'd rather see it as an application. Right now there are dependencies in Core/XE because we don't have IX but that should go away later on. More generally speaking I'd really like that Core/XE is an empty shell in the future, i.e. completely empty and that XWiki instances are built by adding applications. The Panels are one such application but I can envision other navigation/menu applications. People who build these new apps should be able to use them without using the Panels app. Of course, when we have the Application Manager which will allow users to choose their apps the first time they start XWiki we will display the Panels app proeminently. WDYT? Thanks -Vincent > And yes, I'm +1 for the admin app to contain users/groups, rights, > import/export, presentation, panelwizard. > > > Thanks, > Evelina > > -----Original Message----- > From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On > Behalf Of > Vincent Massol > Sent: Tuesday, May 20, 2008 10:20 AM > To: XWiki Developers > Subject: Re: [xwiki-devs] FW: New Admin Design direction > > > On May 20, 2008, at 8:51 AM, Evelina Slatineanu wrote: > >> Hi, >> >> Yes, I've read that document a hundred times but the implementation >> proposal >> changed about that much too :P >> So, yes, Vincent is right about the fact that we should follow the >> interface >> extension direction for the new applications that we are going to >> make but, >> so far, since we don't have the interface extensions I am a little >> bit >> puzzled about the whole thing. What I don't know how to do is: >> >> 1. In what way an application should contribute admin pages to the >> administration application? For this we should have at least some >> classes & >> objects generically defined for each application and the >> administration one >> to read these objects and to be able to know what to include (even >> hardcoded) in the administration menu, as Vincent says. And isn't >> this what >> interface extension application is suppose to do? Please correct me >> if I am >> wrong or I did not understand the request. > > Right now the admin page should hardcode the link to the admin pages > of the apps. This part will be replaced when IX are there. > However before printing the link we should check if the application is > present and don't show it if not (we can check for a known page from > the application). > >> For example, let's say we have the Blog application. For now we have >> global >> administration and space administration. We have the rights, the >> panels and >> the presentation preferences included in the space administration >> for Blog >> space (this is something fixed). Where should go the other things >> that the >> Blog administration application wants to include in the >> administration menu? >> The things that Vincent wants to be hardcoded for now. In the space >> administration page? In another administration page...? And how >> should I >> read these things? From what kind of objects or documents or >> whatever else >> may be used? > > 1) The space preferences (i.e. rights, preferences, etc) should be > separated from the applications IMO. It seems better to have a generic > page that allows to change these space by space rather than delegating > this to the spaces. Especially since Application doesn't mean there's > a space for that application. An application is only a set of pages > right now. > > 2) For the Blog application what I mean by the admin page for Blog is > page in the Blog application that allows changing: > - Blog categories (edit, add new ones) > - A link to the Article Class so that admin users can edit the > stylsheet/template/class definition. > > 3) So in the left menu of the general admin page, we could hardcode a > "Blog" link that links to the blog admin page defined in 2) (and only > display it if the Blog app is present). The same goes for the Panels > app. > >> Until now, after discussing with Jv, Thomas and Sergiu, the idea I >> made >> about the administration application is that it is a set of wiki >> pages used >> to administrate a wiki at global and space level (pretty much the >> same kind >> of application like Panels). But its implementation seems to change >> the more >> we discuss about it (which is a good thing of course) but now I am >> really >> confused. > > I don't see what's changing... Could you be more specific? > > The only thing I'd like NOT to see is (to continue with the Blog > example) to have a blog admin page located in the general admin > application. > > Now one question is whether we consider Import/Export, User/Group > management, Preferences, Panels as 4 applications or not. I think for > now we should consider them as 2: > * the Admin app: Import/Export, User/Group management, Preferences > * the Panels app > > WDYT? > > Thanks > -Vincent > >> Can you help me understand WHAT exactly should I implement for now? >> >> Thanks, >> Evelina >> >> -----Original Message----- >> From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On >> Behalf Of >> Vincent Massol >> Sent: Monday, May 19, 2008 1:06 PM >> To: XWiki Developers >> Subject: [xwiki-devs] New Admin Design direction >> >> Hi, >> >> Some comments I've discussed with JV about implementing >> http://dev.xwiki.org/xwiki/bin/view/Design/ImproveWikiAdministration >> >> I believe we should design it in the following manner: >> >> * The Admin page is a generic empty shell >> * An XWiki instance is made of applications (admin pages like users/ >> groups/configs are part of the admin application too). Examples: >> Blog, >> Calendar, Panels, etc >> * Each application should be able to contribute admin pages to >> configure/administrate itself. These pages should automatically >> appear >> in the left menu on the new admin page. Note that this will require >> interface extensions so right now we would hardcode them in the menu. >> * What it means is that the admin page should link to the admin pages >> located in the applications providing them. >> >> I know we're missing the interface extensions to make this work but >> I'd like that our design for the new admin page works towards this >> goal in mind. >> >> WDYT? >> >> Note: This email was prompted by Evelina asking if it was ok to >> attach >> XARs to be imported in the XWiki.XWikiPeferences page. IMO it's not a >> good thing to do. The XARs should be attached in the ImportExport >> application pages (as it's done now). Now I have no idea how easy or >> hard this is to implement since I haven't dived in the >> implementation. >> >> Thanks >> -Vincent > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

16 years, 4 months

Re: [xwiki-devs] [xwiki-notifications] r9854 - xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/xmlrpc

by Vincent Massol

On May 20, 2008, at 11:27 AM, Sergiu Dumitriu wrote: > vmassol (SVN) wrote: >> Author: vmassol >> Date: 2008-05-19 09:08:08 +0200 (Mon, 19 May 2008) >> New Revision: 9854 >> >> Modified: >> xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ >> xmlrpc/XWikiXmlRpcHandler.java >> Log: >> * Replaced log.info with log.debug calls since we only want to >> print in the console when there are problems or for very important >> information (such as the XWiki version) in order not to "pollute" >> the output. >> * Fixed some copy paste errors ;) > > None of the error messages uses [] around parameters; I thought that > was > a convention for XWiki... It is. Fabio could you please fix them? >> @@ -287,7 +289,7 @@ >> if (!xwiki.getSpaces().contains(spaceKey)) { >> throw new XmlRpcException(String.format("[Space '%s' >> does not exist.]", spaceKey)); > [what's with the brackets?] Same. >> @@ -345,7 +347,7 @@ >> String pageFullName = String.format("%s.%s", spaceKey, >> pageName); >> >> if (!xwiki.exists(pageFullName)) { >> - log.warn(String.format( >> + LOG.warn(String.format( >> "[Page '%s' appears to be in space '%s' but no >> information is available.]", >> pageName)); >> } else { > > This will throw an exception, since it expects 2 arguments instead > of 1. Fabio? Thanks -Vincent PS: Sergiu, this is not code I wrote. I just fixed one aspect of the code which was the usage of info instead of debug for the logs.

16 years, 4 months

Re: [xwiki-devs] FW: New Admin Design direction

by Vincent Massol

On May 20, 2008, at 8:51 AM, Evelina Slatineanu wrote: > Hi, > > Yes, I've read that document a hundred times but the implementation > proposal > changed about that much too :P > So, yes, Vincent is right about the fact that we should follow the > interface > extension direction for the new applications that we are going to > make but, > so far, since we don't have the interface extensions I am a little bit > puzzled about the whole thing. What I don't know how to do is: > > 1. In what way an application should contribute admin pages to the > administration application? For this we should have at least some > classes & > objects generically defined for each application and the > administration one > to read these objects and to be able to know what to include (even > hardcoded) in the administration menu, as Vincent says. And isn't > this what > interface extension application is suppose to do? Please correct me > if I am > wrong or I did not understand the request. Right now the admin page should hardcode the link to the admin pages of the apps. This part will be replaced when IX are there. However before printing the link we should check if the application is present and don't show it if not (we can check for a known page from the application). > For example, let's say we have the Blog application. For now we have > global > administration and space administration. We have the rights, the > panels and > the presentation preferences included in the space administration > for Blog > space (this is something fixed). Where should go the other things > that the > Blog administration application wants to include in the > administration menu? > The things that Vincent wants to be hardcoded for now. In the space > administration page? In another administration page...? And how > should I > read these things? From what kind of objects or documents or > whatever else > may be used? 1) The space preferences (i.e. rights, preferences, etc) should be separated from the applications IMO. It seems better to have a generic page that allows to change these space by space rather than delegating this to the spaces. Especially since Application doesn't mean there's a space for that application. An application is only a set of pages right now. 2) For the Blog application what I mean by the admin page for Blog is page in the Blog application that allows changing: - Blog categories (edit, add new ones) - A link to the Article Class so that admin users can edit the stylsheet/template/class definition. 3) So in the left menu of the general admin page, we could hardcode a "Blog" link that links to the blog admin page defined in 2) (and only display it if the Blog app is present). The same goes for the Panels app. > Until now, after discussing with Jv, Thomas and Sergiu, the idea I > made > about the administration application is that it is a set of wiki > pages used > to administrate a wiki at global and space level (pretty much the > same kind > of application like Panels). But its implementation seems to change > the more > we discuss about it (which is a good thing of course) but now I am > really > confused. I don't see what's changing... Could you be more specific? The only thing I'd like NOT to see is (to continue with the Blog example) to have a blog admin page located in the general admin application. Now one question is whether we consider Import/Export, User/Group management, Preferences, Panels as 4 applications or not. I think for now we should consider them as 2: * the Admin app: Import/Export, User/Group management, Preferences * the Panels app WDYT? Thanks -Vincent > Can you help me understand WHAT exactly should I implement for now? > > Thanks, > Evelina > > -----Original Message----- > From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On > Behalf Of > Vincent Massol > Sent: Monday, May 19, 2008 1:06 PM > To: XWiki Developers > Subject: [xwiki-devs] New Admin Design direction > > Hi, > > Some comments I've discussed with JV about implementing > http://dev.xwiki.org/xwiki/bin/view/Design/ImproveWikiAdministration > > I believe we should design it in the following manner: > > * The Admin page is a generic empty shell > * An XWiki instance is made of applications (admin pages like users/ > groups/configs are part of the admin application too). Examples: Blog, > Calendar, Panels, etc > * Each application should be able to contribute admin pages to > configure/administrate itself. These pages should automatically appear > in the left menu on the new admin page. Note that this will require > interface extensions so right now we would hardcode them in the menu. > * What it means is that the admin page should link to the admin pages > located in the applications providing them. > > I know we're missing the interface extensions to make this work but > I'd like that our design for the new admin page works towards this > goal in mind. > > WDYT? > > Note: This email was prompted by Evelina asking if it was ok to attach > XARs to be imported in the XWiki.XWikiPeferences page. IMO it's not a > good thing to do. The XARs should be attached in the ImportExport > application pages (as it's done now). Now I have no idea how easy or > hard this is to implement since I haven't dived in the implementation. > > Thanks > -Vincent

16 years, 4 months

[xwiki-devs] FW: New Admin Design direction

by Evelina Slatineanu

Hi, Yes, I've read that document a hundred times but the implementation proposal changed about that much too :P So, yes, Vincent is right about the fact that we should follow the interface extension direction for the new applications that we are going to make but, so far, since we don't have the interface extensions I am a little bit puzzled about the whole thing. What I don't know how to do is: 1. In what way an application should contribute admin pages to the administration application? For this we should have at least some classes & objects generically defined for each application and the administration one to read these objects and to be able to know what to include (even hardcoded) in the administration menu, as Vincent says. And isn't this what interface extension application is suppose to do? Please correct me if I am wrong or I did not understand the request. For example, let's say we have the Blog application. For now we have global administration and space administration. We have the rights, the panels and the presentation preferences included in the space administration for Blog space (this is something fixed). Where should go the other things that the Blog administration application wants to include in the administration menu? The things that Vincent wants to be hardcoded for now. In the space administration page? In another administration page...? And how should I read these things? From what kind of objects or documents or whatever else may be used? Until now, after discussing with Jv, Thomas and Sergiu, the idea I made about the administration application is that it is a set of wiki pages used to administrate a wiki at global and space level (pretty much the same kind of application like Panels). But its implementation seems to change the more we discuss about it (which is a good thing of course) but now I am really confused. Can you help me understand WHAT exactly should I implement for now? Thanks, Evelina -----Original Message----- From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On Behalf Of Vincent Massol Sent: Monday, May 19, 2008 1:06 PM To: XWiki Developers Subject: [xwiki-devs] New Admin Design direction Hi, Some comments I've discussed with JV about implementing http://dev.xwiki.org/xwiki/bin/view/Design/ImproveWikiAdministration I believe we should design it in the following manner: * The Admin page is a generic empty shell * An XWiki instance is made of applications (admin pages like users/ groups/configs are part of the admin application too). Examples: Blog, Calendar, Panels, etc * Each application should be able to contribute admin pages to configure/administrate itself. These pages should automatically appear in the left menu on the new admin page. Note that this will require interface extensions so right now we would hardcode them in the menu. * What it means is that the admin page should link to the admin pages located in the applications providing them. I know we're missing the interface extensions to make this work but I'd like that our design for the new admin page works towards this goal in mind. WDYT? Note: This email was prompted by Evelina asking if it was ok to attach XARs to be imported in the XWiki.XWikiPeferences page. IMO it's not a good thing to do. The XARs should be attached in the ImportExport application pages (as it's done now). Now I have no idea how easy or hard this is to implement since I haven't dived in the implementation. Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

16 years, 4 months

← Newer
1
...
4
5
6
7
8
9
10
...
16
Older →

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 May 2008