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
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
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.
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
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.
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
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
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.
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
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