Hello,
I am working on creating blog entries using xwiki. I was wondering if it would be possible to create a template for the blog entries so that they will be more structured?
Thank you for your time and help!
Hande Aksac
Hi,
Since I'm rewriting the new Rendering component
(see http://dev.xwiki.org/xwiki/bin/view/Design/NewRenderingArchitecture)
, we need to finalize the new syntax we want to have.
Right now I'v planned to use the same wiki syntax as now
(http://platform.xwiki.org/xwiki/bin/view/Main/
XWikiSyntax#HTextStyles) with only one change: all macros now need to
be closed.
For example: {macro}...{/macro} and {macro:text|param=value|.../}
Is that ok with everyone or do we want to make changes?
Thanks
-Vincent
Hi,
I have installed the xwiki.war complete all the intructions for Tomcat
Servlet and MySQL Database configuration. But my xwiki is not working
properly ,its giving me the following error.
I have installed the enterprise version of xwiki war. I have gone throught
the forum to see if anyone's got a similar error , but looks like its just
me, just in case if i have missed this error posted by some user and if
there was a solution posted earlier, please point me to that link.
Here is the exception what i get
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException: Error number 3 in 0: Could not initialize
main XWiki context
Wrapped Exception: Error number 3001 in 3: Cannot load class
com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from
param xwiki.store.migration.manager.class
Wrapped Exception: Error number 0 in 3: Exception while hibernate execute
Wrapped Exception: Hibernate Dialect must be explicitly set
org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:433)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
root cause
com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main
XWiki context
Wrapped Exception: Error number 3001 in 3: Cannot load class
com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from
param xwiki.store.migration.manager.class
Wrapped Exception: Error number 0 in 3: Exception while hibernate execute
Wrapped Exception: Hibernate Dialect must be explicitly set
com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:328)
com.xpn.xwiki.XWiki.getXWiki(XWiki.java:515)
com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:136)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
note The full stack trace of the root cause is available in the Tomcat logs.
ANd i have installed JDK 1.5.
Can please let help me out with this error.
Thanks,
Nishii
--
View this message in context: http://n2.nabble.com/Could-not-initialize-main-XWiki-context-tp534219p53421…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
We need a deprecation strategy, i.e. decide for how long we keep
@deprecated methods/classes.
I propose to keep them for 2 full releases after the current version
is released as final.
For example if a method is deprecated in, say Core 1.3M2 then the
method will be removed in 1.6M1. Of course any major new release can
deprecate anything so a XWiki 2.0 is expected to break backward
compatibility.
So for methods deprecated in 1.0 we can remove them in 1.3M1, M2, etc.
WDYT?
If ok then I'll add this to our dev practice guide too.
Note that for this to be easy anyone deprecating methods should add
the information of when it was deprecated. For example:
/**
* @param time the time in milliseconds
* @return the time delta in milliseconds between the current
date and the time passed
* as parameter
* @deprecated replaced by {@link
com.xpn.xwiki.api.Util#getTimeDelta(long)} since 1.3M2
*/
public int XWiki.getTimeDelta(long time)
{
return this.util.getTimeDelta(time);
}
Here's my +1
Thanks
-Vincent
Hello Xwiki-Devs,
I am not quite sure if this one is just a stupid question I haven't been
able to find an answer for, or if it is just impossible.
Situation is this: If you hava a link in a page e.g. "[GrannySmith]" and
and this page doesn't exist yet (so it'll get a questionmark as marker),
as soon as somebody clicks on that link xwiki will suggest to create a
new Page or go straight to the editor. So far so clear. Now for instance
I have a xwiki class called "Apple" can I create a link that mandates
that the newly created page should be of the class "Apple" (respectively
should have an object of "Apple")? Or is there any other way to
accomplish this?
thanks and greetings
Jonas
Hi devs,
The first proposal is about introducing two $xwiki.countDocuments
methods, one that accepts a simple hql query, and one that accepts a
parametrized query and a list of parameter values. These work like
searchDocuments, but instead of prefixing the query fragment with
'select doc.fullName from XWikiDocument as doc', it will prefix it with
'select count(*) from XWikiDOcument as doc'.
This will allow to count documents without using a programming-protected
query, and without retrieving all the documents and count the results.
Such a method is needed for paging results, for example.
The second proposal is a temporary hack for hiding documents. The idea
is to add a new field in the XWikiDocument class, 'hidden', which will
be automatically used in searchDocuments and countDocuments to filter
out special documents. This is a workaround until we will be able to tag
special documents or spaces, and will allow to create special documents
needed for an application inside the main application's space, instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
To show these documents (for admins, for example) we could add another
searchDocuments method which accepts a boolean parameter that enables or
disables the filter on the 'hidden' property.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hello,
has anybody the same slow and choppy scrolling issue under Firefox3 with
XWiki?
Apparently this is linked to the fixed CSS background for the header menu...
It doesn't appear on all hardware/OS configurations but lots of people
complain about it.
As XWiki uses a fixed background by default, I preferred warning you because
this is really a pain using xwiki under FF3 on my computer :)
(if you remove the "fixed" CSS field, it works betteeeeeeeer)
regards
Pascal
Hi devs,
I'd like to apply http://jira.xwiki.org/jira/browse/XWIKI-2667 , but one
thing I'd like to change is the format of the log messages. The current
patch uses String.format, but I prefer MessageFormat, as it is more
expressive, and it is already used by the localization tool.
So:
1. We use String.format, because:
- it is "simpler" (some say)
- it is familiar to C/C++ programmers
- it is a bit more customizable at the finer level
- the code is already written
2. We use MessageFormat, because:
- it is already used for localization strings
- it is more expressive (I really like the "choice" format)
- it is apparently less customizable, but it uses good defaults (I'd
rather specify that I want a "long" date format than a "DD MMMM HH:mm:ss
z" format)
- the changes are minimal
- I for one prefer this syntax, rather than the old printf one.
My +1 for option 2.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/