Hi,
I'm about to commit silk icons so that we bundle them with our webapp.
I want to commit them under xwiki-web-standard but we don't have any
standard place where to put this kind of common resources.
We currently have common resources (js and icons) under the root of
our webapp (yui,xwiki.js,etc) and in the albatross skin (most of
them).
Those resources are independant from a particular skin and thus
shouldn't be placed in one of them (at least imho).
I suggest that we move javascript and icon files out of albatross and
that we introduce a new rule: don't put javascript in our skins.
Note that I'm not suggesting to deprecate our baseskin mechanism since
being able to use inheritance between skins is a good thing (it allows
to customize only part of the styles).
Proposal 1
========
Tree:
xwiki/
-- resources/
---- icons/
------ tango/
------ silk/
---- javascript/
------ lib/ (we could minimize files in this folder at build time with rhino)
-------- prototype/
-------- scriptaculous/
-------- yui/
------ xwiki/ (files get from this directory would be parsed since
almost xwiki js files contains velocity calls)
-- skins/
---- toucan/
-- templates/
-- META-INF/
-- WEB-INF/
Getter methods:
Util.getJavascriptResource(String filename)
Util.getIconResource(String filename)
The resources directory would be held by xwiki-web-standard.
Note that this way of getting resources would prevent overloading of
icons and javascript from the skin (unlike xwiki.getSkinFile).
Proposal 2
========
Tree:
xwiki/
-- skins/
---- commons/
------ icons/
-------- tango/
-------- silk/
------ javascript/
-------- lib/ (we could minimize files in this folder at build time with rhino)
---------- prototype/
---------- scriptaculous/
---------- tinymce/
---------- yui/
-------- xwiki/ (files get from this directory would be parsed since
almost xwiki js files contains velocity calls)
---- toucan/
-- templates/
-- META-INF/
-- WEB-INF/
Getter methods:
Modify getSkinFile to look into commons after looking into skin and
baseskin (toucan then albatross in our distrib).
The skins/commons/ directory would be held by xwiki-web-standard.
I'd also like to take advantage of this refactoring to remove some
files from the root of our webapp if we all agree:
- JSTrim*
- freemind (unused)
- s5 (moved out of XE 2 years ago IIRW)
WDYT ?
Thanks,
JV.
On Jan 27, 2009, at 12:30 PM, jvdrean (SVN) wrote:
> Author: jvdrean
> Date: 2009-01-27 12:30:04 +0100 (Tue, 27 Jan 2009)
> New Revision: 15759
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/resources/
> ApplicationResources.properties
> platform/xwiki-applications/trunk/administration/src/main/
> resources/XWiki/AdminGeneralSheet.xml
> Log:
> XAADMINISTRATION-17 : Display date format option in the general
> section of the administration
>
> Implemented.
>
> Modified: platform/core/trunk/xwiki-core/src/main/resources/
> ApplicationResources.properties
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/resources/
> ApplicationResources.properties 2009-01-27 11:28:16 UTC (rev 15758)
> +++ platform/core/trunk/xwiki-core/src/main/resources/
> ApplicationResources.properties 2009-01-27 11:30:04 UTC (rev 15759)
> @@ -158,6 +158,7 @@
> registration=Registration
> multilingual=Multi Lingual
> default_language=Default Language
> +dateformat=<a href="http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HDateform…
> ">Date format</a>
hmm... do we want this? Are we already linking from the source to
external documentation?
The risk is that it's going to be very easy to break the link when we
reorganize documentation and that it requires internet connection.
The alternative could be to have a tooltip with the format defined in
there.
WDYT?
Thanks
-Vincent
>
> authenticate_view=Prevent unregistered users from viewing pages,
> regardless of the page or space rights
> authenticate_edit=Prevent unregistered users from editing pages,
> regardless of the page or space rights
> baseskin=Base Skin
>
> Modified: platform/xwiki-applications/trunk/administration/src/main/
> resources/XWiki/AdminGeneralSheet.xml
> ===================================================================
> --- platform/xwiki-applications/trunk/administration/src/main/
> resources/XWiki/AdminGeneralSheet.xml 2009-01-27 11:28:16 UTC (rev
> 15758)
> +++ platform/xwiki-applications/trunk/administration/src/main/
> resources/XWiki/AdminGeneralSheet.xml 2009-01-27 11:30:04 UTC (rev
> 15759)
> @@ -58,7 +58,7 @@
> <content>### Administrate general wiki preferences, at global level
> #set($legend = ["language", "editor", "admin", "server"])
> #set($params = $util.hashMap)
> -#set($params.language = ["multilingual", "languages" ,
> "default_language"])
> +#set($params.language = ["multilingual", "languages" ,
> "default_language", "dateformat"])
> #set($params.editor = ["editor"])
> #set($params.admin = ["admin_email"])
> #set($params.server = ["smtp_server"])
Devs,
I've been brainstorming about implementing office importer functionality in
wysiwyg where the user will be able to upload a document and have it's
content imported into the current page being edited (i.e into the wysiwyg
editor). Note that we already have the copy/paste functionality implemented.
The first problem I see is that GWT doesn't have a way to upload a file with
a usual RPC call. Given the parameters, following is one possible way out of
this problem,
1. Define an OfficeImporterServlet which mapps to /xwiki/officeimporter
2. Let the office importer wysiwyg plugin make a POST request to this
servlet with a FileUpload widget (
http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/use…
).
3. The servlet will import the document into xhtml and write back the result
as the response.
4. Office importer wysiwyg plugin in turn takes the result and put it into
the wysiwyg editor.
And the second problem arises when there are non-textual content (ex.
images) in the document submitted. In this case, office importer servlet
must attach these files into the wiki page which is being edited. Now, if
the user decides to cancel the whole edit operation just after the import
operation, there must be a way to remove those attachments. How can we do
this? (For the moment I don't know how to handle this case)
Please let me know if you have any comments :)
Thanks.
- Asiri
Hi,
In order to better organize our SVN/JIRA I propose to implement the
following refactoring:
1) Release all platform modules simultaneously. Rationale: make it
easy to release and to ensure all versions work together.
2) Remove notion of core. Keep only notion of platform. It's up the
products/projects to hand pick whatever components they need from the
platform.
3) Move in SVN platform/core/* to platform/components/ except for
platform/core/xwiki-core which is moved to platform/xwiki-core/ (while
waiting to be split into components)
4) in JIRA create a new category named "XWiki Platform Components" and
have one jira project for each top level module in platform/
components/. Move the "XWiki Core" jira project from the "XWiki Core &
Products" category to the "XWiki Platform Components" category.
5) In JIRA rename "XWiki Core & Products" to "XWiki Top Level Projects"
6) Create some tools on dev.xwiki.org to help with releases (using
swizzle jira). Namely:
- a tool to automatically add a version to a set of jira projects
(we'll need to do that to manipulate all jira projects in "XWiki
Platform Components" all together). Same to release a version
WDYT?
Note that I've tried imagining keeping all platform modules under the
same jira project but I've ruled it out since that doesn't work well
for several reasons:
* there's no notion of sub-components in jira which would mean
creating hundreds of jira components...
* we already have some modules in separate jira projects
* it may happen that we may want to occasionally release a module
separately in the future for some reason
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net
Hi devs,
column sorting (as shown in table generated by "xwiki.result") does only
string sort. Is there any way to do alphanumeric sort?
for example sorting does something like this: a1, a10, a11, a2, a21,
a3,a4 ..... , a9, ......
I would like to get something like this: a1, a2, a3, a4, ... a9....
a10, a11, a21, ......
Also is there a way just to do the numeric sort?
Regards......
Groovy 1.6RC2 is out. We could upgrade.
Thanks
-Vincent
Begin forwarded message:
> From: Guillaume Laforge <glaforge(a)gmail.com>
> Date: January 22, 2009 10:25:26 PM CEST
> To: Groovy User <user(a)groovy.codehaus.org>, Grails Users <user(a)grails.codehaus.org
> >, GroovyDev <dev(a)groovy.codehaus.org>, announce(a)groovy.codehaus.org
> Subject: [ossgtp] Groovy 1.6-RC-2 is out!
> Reply-To: ossgtp(a)yahoogroups.com
>
> Hi all,
>
> The Groovy development team and SpringSource are pleased to announce
> the second candidate for Groovy 1.6.
> This release is a bug fix release, and as you can see by looking at
> the JIRA issues closed -- almost a hundred, a lot of work has been
> done to ensure that our next major release is of great quality, and
> various improvements have been introduced -- check for instance the
> much nicer and thourough output of GroovyDoc!
>
> This version obviously also contain all the performance improvements
> and features of the latest betas and RC. You can read more about
> them by reading the previous announcements:
> Groovy 1.6-beta-1
> Groovy 1.6-beta-2
> Groovy 1.6-RC-1
> You can download Groovy 1.6-RC-2 at the usual place: http://groovy.codehaus.org/Download
>
> And now, we need your help to test drive this release candidate! We
> need you to find possible critical bugs or regressions, so please
> make sure you try 1.6-RC-2 with your project, to be able to upgrade
> as soon as possible to the latest and greatest Groovy.
>
> We're looking forward to your feedback.
>
> Thank you all for your hard work and your contributions.
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one