On Jun 26, 2008, at 7:00 PM, Evelina Slatineanu wrote:
> Hi all,
>
>
>
> For the new Administration application to work properly in an empty
> wiki
> (create users, groups, set rights etc), the following files have to
> be moved
> from XE to Administration:
>
>
>
> Xwiki.Admin
>
> Xwiki.Users
>
> Xwiki.XwikiUserSheet
>
> Xwiki.XWikiUserTemplate
>
> Xwiki.AdminGroup
>
> Xwiki.AllGroup
>
> Xwiki.Groups
>
> Xwiki.XwikiGroupSheet
>
> Xwiki.XwikiGroupTemplate
>
> Xwiki.Rights
>
> Xwiki.GlobalRights
>
> Xwiki.DefaultSkin
>
> Xwiki.Skins
>
> Xwiki.XwikiPreferences
>
>
>
> I already sent the patch to JV, we only need votes. I'm +1
+1
However we need a info box to install the Admin app when the database
doesn't contain it and when the user clicks on Administration. This is
while we wait for the Setup Wizard which should force the installation
of the admin app.
Thanks
-Vincent
Hi all,
The hsqldb standalone zip distribution for XWiki Watch 1.0 RC 1 has been
released with wrong hibernate configuration file so you should use the
.jar installer until the XWiki Watch 1.0 Release Candidate 2 will be
released with the correct configuration (which is not very far in the
future).
Regards,
the XWiki Watch development team
Hi guys,
I know the installation/update is not that complicated and I discussed that
on this list some time ago, too. Nevertheless I have an (incomplete) idea to
this topic. Maybe you had this already, maybe it's not a good idea at all,
however:
Recently I had to modify the login.vm file on the server as I found no way
to change this page within XWiki. By this time I realized that I have to
write down my modification for the next update. So I thought maybe it would
be possible to change the update process a bit.
What about a web-updater? If you would create a web-updater you could show
the troublesome files and show the differences (maybe by generating for each
and every file a MD5 hash by the time you release a version) and let the
user decide how to proceed (like in Linux when an update tries to change
grub). In addition to that you could stream important release information
into this 'update'-area (new version, security stuff, etc. and, if the user
is willing to provide them, some usage-statistics). Maybe you could even
differentiate between core and plugin updates...
Cheers,
Squirrel
On Jun 26, 2008, at 1:58 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2008-06-26 01:58:47 +0200 (Thu, 26 Jun 2008)
> New Revision: 10823
>
> Modified:
> xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> pdf/impl/PdfExportImpl.java
> Log:
> XWIKI-2498: Exporting a page with an image to PDF fails on Jetty
> Fixed.
>
>
> Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/
> xwiki/pdf/impl/PdfExportImpl.java
> ===================================================================
> --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> pdf/impl/PdfExportImpl.java 2008-06-25 23:35:34 UTC (rev 10822)
> +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> pdf/impl/PdfExportImpl.java 2008-06-25 23:58:47 UTC (rev 10823)
> @@ -26,6 +26,7 @@
> import com.xpn.xwiki.objects.BaseObject;
> import com.xpn.xwiki.pdf.api.PdfExport;
> import com.xpn.xwiki.util.Util;
> +import com.xpn.xwiki.web.Utils;
> import com.xpn.xwiki.web.XWikiRequest;
> import info.informatica.doc.dom4j.CSSStylableElement;
> import info.informatica.doc.dom4j.XHTMLDocument;
> @@ -221,7 +222,15 @@
> try {
> tempdir.mkdirs();
> context.put("pdfexportdir", tempdir);
> + boolean useLocalPlaceholders = !
> Utils.arePlaceholdersEnabled(context);
> + if (useLocalPlaceholders) {
> + Utils.enablePlaceholders(context);
> + }
> String content =
> context.getWiki().parseTemplate("pdf.vm", context);
> + if (useLocalPlaceholders) {
> + content = Utils.replacePlaceholders(content,
> context);
> + Utils.disablePlaceholders(context);
> + }
Shouldn't this be done in the rendering engine code?
For example in the new rendering we don't need this so it would be
easier to integrate the new rendering if this code was only found in
the old rendering code.
WDYT?
Thanks
-Vincent
>
Hi all,
For the new Administration application to work properly in an empty wiki
(create users, groups, set rights etc), the following files have to be moved
from XE to Administration:
Xwiki.Admin
Xwiki.Users
Xwiki.XwikiUserSheet
Xwiki.XWikiUserTemplate
Xwiki.AdminGroup
Xwiki.AllGroup
Xwiki.Groups
Xwiki.XwikiGroupSheet
Xwiki.XwikiGroupTemplate
Xwiki.Rights
Xwiki.GlobalRights
Xwiki.DefaultSkin
Xwiki.Skins
Xwiki.XwikiPreferences
I already sent the patch to JV, we only need votes. I'm +1
Thanks, Evelina
Hi,
In the new rendering code I need to call some code that transforms
[[[wiki:][Space.]][Doc]] into a link. I'm proposing to introduce 2 new
classes/components in Core:
* DocumentName: Represents a Document's Name. It'll have 3 properties:
- String wiki
- String space
- String page
* DocumentNameFactory: Create a DocumentName from a string
representing a Document's name. Transforms [[[wiki:][Space.]][Doc]]
into a DocumentName object.
* The DocumentNameFactory would depend on the Execution component so
that it can use the current wiki, current space and current document
if these are not specified.
* This raises the question as to whether we should continue passing a
String representing a document name in our APIs in the future or
instead pass a DocumentName. I'm not yet sure what is the best answer
to this...
* Other question: In the Document object do we store the DocumentName
object or do we store instead only Space and Wiki objects? If it's the
latter then we need to fetch them from the DB which takes time. We
could also decide to only fetch them when requested with getSpace()
and getWiki() (i.e. lazy loading).
* BTW this also raises the question as to whether we want to have a
representation for space and wiki or not and instead only use tags, in
which case a document name is simply a String like "mypage". But then
it should be unique. So it could also be made of a list of identity
tags as in: "space=sp1,sp2:wiki:wiki1:language=fr:mypage". Or we could
standardize it as "wiki1:sp1,sp2:fr:mypage" and have the
DocumentNameFactory transform it into tags. In that case the
DocumentName object would be a Map of tags + the document name
("mypage"). I think we need to decide ASAP if we want to keep the
strict and hardcoded notion of Wiki>Space>Document>Object>Property or
instead go full tags since this changes completely the v2 interfaces
and code we're writing.
Let me know what you think.
Thanks
-Vincent
Yes you are right. But in toucan skin they using png for panel design.
If i change the style its reflecting for all the panels. And in the
style.css they have handled those style.
--
Prathap
On Thu, Jun 26, 2008 at 1:26 PM, Vincent Massol <vincent(a)massol.net> wrote:
Yes it's possible. Just look at the generated page in your browser in
source view to know to what class/id to attach to.
-Vincent
On Jun 26, 2008, at 9:46 AM, Prathap Pandian wrote:
> Hi,
>>
> Is it possible to apply separate CSS for each panels in the xwiki.
>
> If its possible can any one help me to change.
>
> When i am changing the CSS is applying for all the panels.
______________________________
>
> _________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
Hi,
Is it possible to apply separate CSS for each panels in the xwiki.
If its possible can any one help me to change.
When i am changing the CSS is applying for all the panels.
--
Prathap
On Jun 26, 2008, at 1:35 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2008-06-26 01:35:34 +0200 (Thu, 26 Jun 2008)
> New Revision: 10822
>
> Modified:
> xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> doc/XWikiDocument.java
> Log:
> Fixing the build
ooops sorry... i had started the build to check it worked but forgot
to look at the results...
Thanks
-Vincent