xwiki-devs December 2009

xwiki-devs@xwiki.org

32 participants
100 discussions

Re: [xwiki-devs] [xwiki-notifications] r25403 - in platform: skins/trunk/albatross/src/main/resources/albatross skins/trunk/colibri/src/main/resources/colibri skins/trunk/toucan/src/main/resources/toucan xwiki-applications/trunk/panels/src/main/resources/Panels

by Sergiu Dumitriu

On 12/02/2009 05:23 PM, jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-12-02 17:23:27 +0100 (Wed, 02 Dec 2009) > New Revision: 25403 > > Modified: > platform/skins/trunk/albatross/src/main/resources/albatross/colorsblack.css > platform/skins/trunk/albatross/src/main/resources/albatross/screenlayout.css > platform/skins/trunk/albatross/src/main/resources/albatross/style.css > platform/skins/trunk/colibri/src/main/resources/colibri/colibri.css > platform/skins/trunk/toucan/src/main/resources/toucan/toucan.css > platform/xwiki-applications/trunk/panels/src/main/resources/Panels/Navigation.xml > platform/xwiki-applications/trunk/panels/src/main/resources/Panels/PanelWizard.xml > platform/xwiki-applications/trunk/panels/src/main/resources/Panels/RightsHelp.xml > platform/xwiki-applications/trunk/panels/src/main/resources/Panels/RightsTips.xml > Log: > XAPANELS-98 : Accordion section titles arbitrarily use level 6 headings > XSALBATROSS-71 : Accordion section titles arbitrarily use level 6 headings > XSTOUCAN-137 : Accordion section titles arbitrarily use level 6 headings > XSCOLIBRI-160 : Accordion section titles arbitrarily use level 6 headings > > Modified: platform/skins/trunk/albatross/src/main/resources/albatross/colorsblack.css > =================================================================== > --- platform/skins/trunk/albatross/src/main/resources/albatross/colorsblack.css 2009-12-02 16:22:14 UTC (rev 25402) > +++ platform/skins/trunk/albatross/src/main/resources/albatross/colorsblack.css 2009-12-02 16:23:27 UTC (rev 25403) > @@ -520,7 +520,7 @@ > border-top: 1px solid #384554 !important; > border-bottom: 1px solid #384554 !important; > } > -.panel .accordionTabTitleBar h6{ > +.panel .accordionTabTitleBar h1{ This might break the layout for other custom accordions. It would be better to leave the old rule in place, too .panel .accordionTabTitleBar h6, .panel .accordionTabTitleBar h1 { > margin: 0px; > color: #FFF !important; > font-style: normal !important; > @@ -531,7 +531,7 @@ > border-bottom: 2px solid #384554 !important; > border-top: 1px solid #384554; > } > -.panel .accordionTabTitleBar h6:hover{ > +.panel .accordionTabTitleBar h1:hover{ > background: transparent url("icons/black-more-3.png") right center no-repeat !important; > } -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years

[xwiki-devs] [VOTE] Move Dodo + Finch skins to the contrib repo?

by Vincent Massol

Hi, Since we're not maintaining the dodo/finch skins anymore I'd suggest we move them out of the main code base into the contrib project. More precisely I propose to move them to: http://svn.xwiki.org/svnroot/xwiki/contrib/retired/ We also need to update the skins page on xwiki.org to explain the skins are no longer maintained (but can be resurrected by anyone interested). Here's my +1 Thanks -Vincent

15 years

[xwiki-devs] Dodo and Finch skins location?

by Vincent Massol

Hi, What should we do with the Dodo and Finch skins? Right now they sit in the platform as any other skin. However they're not in a working state. I've just tried Finch and the home doesn't display nicely in it. We have 2 options I can think of: 1) we leave old/non-working modules in platform (as they are now) 2) we move them to a retired location. In this case we could move them to the contrib repo in retired/. This leaves the door open to anyone interested to resurrect them (even if it's a bit hidden, but we could make that more visible). The only small issue (maybe it's not one) is that name "contrib". Another option would be to create an "attic" top level project for retried projects. I can also think of some plugins that could go there (alexa, adwords, etc) - We'd need to verify that they don't work since otherwise they probably don't need to be moved. We could also define a rule to move stuff to the attic: - the feature is not working anymore - there's been no commit for one year Obviously anyone interested in reviving the retired code could do so and move it back to the platform at any time. Any idea on this? Thanks -Vincent

15 years

[xwiki-devs] [Proposal] Add a component for javascript and css caching/compression/concatenation

by Caleb James DeLisle

I'd like to start making a component to manage javascript and css, I imagine the interface as follows: /** * ExternalContentManager is able to take content which is external to the HTML (eg: Javascript and CSS) * and register it with specifications for the context, when the context meets these specifications * (for example the value of the key: "wiki" is "xwiki" or the value of the key "doc" is "Main.WebHome" or both) * the script will be imported when getImportString() is called. */ public interface ExternalContentManager /** * The first three methods compare the configuration to the ExecutionContext * good for the future but not very useful at the moment. */ /** * @param The source of the external content * @param config The configuration for when and how to use this source. */ void register(ExternalContentSource source, ExternalContentConfig config) /** * @param The source of the external content * @param config The configuration for when and how to use this source, header, footer and minify are disregarded */ void unregister(ExternalContentSource source, ExternalContentConfig config) /** * Unregister everything for this configuration, null unregisters everything. * @param config The configuration for when and how to use this source, header, footer and minify are disregarded */ void unregisterAll(ExternalContentConfig config) /** * Because most information is still stored in the XWikiContext * add compatibility methods which compare the whenToUse parameter in the * configuration to the XWikiContext. */ /** * @param The source of the external content * @param config The configuration for when and how to use this source. */ void registerx(ExternalContentSource source, ExternalContentConfig config) /** * @param The source of the external content * @param config The configuration for when and how to use this source, header, footer and minify are disregarded */ void unregisterx(ExternalContentSource source, ExternalContentConfig config) /** * Unregister everything for this configuration, null unregisters everything. * @param config The configuration for when and how to use this source, header, footer and minify are disregarded */ void unregisterAllx(ExternalContentConfig config) /** * @return A string of HTML which contains import statments for all of the scripts which should * be imported based on the values in the ExecutionContext and XWikiContext. */ String getImportString() } /** * ExternalContentConfig is a set of configurations to be passed to the ExternalComponentManager when * adding a source to be used. */ interface ExternalContentConfig extends Map { /** * @param header This is prepended to the source after minifying but before concatination, use for license info */ void setHeader(String header) /** * @param footer This is appended to the source after minifying but before concatination */ void setFooter(String footer) /** * @param shouldMinify make this false to avoid minifying the source, default: true */ void shouldMinify(boolean shouldMinify) /** * @param whenToUse Each of the values must match value given by the same key from the context after toString() is called on it. */ void useSourceWhen(Map<String, String> whenToUse) } public interface ExternalContentSource { public enum SourceType { /** The source comes from a file in the servlet context. */ SERVLET_CONTEXT, /** The source comes from a jar in the classpath. */ CLASSPATH, /** The source comes from an unknown origin and the code is given in this string. */ STRING, } /** * Set the origin of the source, if sourceType is a string then this is the source itself. */ void SetOrigin(String origin) /** * Get the code of the source from where it is stored. */ String() getOrigin() /** * Set the type of source this is. */ void SetType(SourceType type) /** * Get the type of surce this is. */ SourceType GetType() } I would like to implement this interface using jawr to compress, concatenate, and cache the sources, but the interface does not require any more than what skinx does except not on a per-request basis. What do you think? Any other ideas. Caleb James DeLisle

15 years

[xwiki-devs] What does "import translation file" mean? It doesn't work.

by Zhaolin Feng

I'm trying to translate the XE Simplified Chinese but have a question. On this page: http://l10n.xwiki.org/xwiki/bin/view/XE/XWikiCoreResources, there is a link "Import/reimport default language file". And after each specific language, there is also an "import" link. What it means? I guess it will pull the resource file from the svn trunk, extract all (variable names, English text) pairs, so that someone can start providing more translations. I'm I right? But the import functionality seems broken. When I click "confirm import" it says, "Error number 4001 in 4: Error while parsing velocity page XE.XWikiCoreResources Wrapped Exception: Failed to evaluate content with id XWiki Core Resources" -- -- Currahee! We stand alone together!

15 years

[xwiki-devs] Introduce XML based syntax mapping events/XDOM

by Thomas Mortagne

Hi all, Since i finished a first POC, I would like to introduce a new XML based syntax. the goal is to provide an easy to parse exact mapping of the rendering events. You can look at http://dev.xwiki.org/xwiki/bin/view/Design/xmlsyntax for more details. Would be great to have comments about this. The main things to discuss are: - what XML syntax exactly (http://dev.xwiki.org/xwiki/bin/view/Design/xmlsyntax#HProposedformat) - what syntax identifier (http://dev.xwiki.org/xwiki/bin/view/Design/xmlsyntax#Hfindagoodsyntaxidenti…) The first use case for this is the support of generic markers in XHTML: instead of having specialized macro marker in XHTML comment serialized in a generic, easy to parse and exact repesentation of a XDOM branch that as been replaced by something else during a transformations. So WDYT ? -- Thomas

15 years

[xwiki-devs] XOO

by Cristina Scheau

Hi all! How are you? I apologize that I wasn't so active recently. I spent all my time with tasks from my job and my Master. Now I have a little bit more free time (in the evenings and weekends) and I would like to continue the XOO project. I'm not clear what should I exactly do next and maybe you can help me with your feedback and ideas. I'd really like to contribute again to the XWiki software . Although I was not so happy with the API from OpenOffice, last summer was a really interesting experience for me. Thank you, Cristina S.

15 years

[xwiki-devs] Can XWiki benefit from Google AJAX Libraries API ?

by Asiri Rathnayake

Link: http://code.google.com/apis/ajaxlibs/ Article about how it can make websites fast: http://radar.oreilly.com/2009/11/steve-souders-making-web-sites.html XWiki web gurus, can XWiki benefit from this? Is it worth considering? Thanks. - Asiri

15 years

[xwiki-devs] [Discussion] "noupdate" flag and it's usage in packager plugin

by Asiri Rathnayake

Hi Devs, in XWiki::initXWiki(XWikiConfig config, XWikiContext context, XWikiEngineContext engine_context, boolean noupdate) method signature, the flag "noupdate" indicates whether the database should be updated or not. But as far as I can understand, it's meaning is reversed: - if "noupdate" is true -> You can update the database and install data into it (like define major xwiki classes etc.). - if "noupdate" is false -> You should not add anything into the database. (I guess this means you can only create the database schemas.) One observation I made though is that "noupdate" is actually used only in the following code segment: <code> // Make sure these classes exists if (noupdate) { initializeMandatoryClasses(context); getStatsService(context); } </code> * Question:- Do we really need this flag? The other problem is that pckager plugin is using a version of XWiki constructor that sets this flag to "false" by default: see http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-package… http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-core/src/main/… proof. This means when we are packaging the database (hsqldb), none of the mandatory classes are packaged. They will only be initialized when XE is loaded for the first time. * Question:- Is this the desired behavior? Apperantly I have introduced a bug (sort of) because XWiki.WikiMacroClass & XWiki.WikiMacroParameterClass are initialized inside if(noupdate){} clause but I have invoked registerWikiMacros(); call outside of it (in XWiki::initXWiki()). This makes hsqldb database build report an exception because wiki macro registration code throws an exception if it cannot find the necessary xwiki class definitions. I can fix this error by simply moving registerWikiMacros(); call inside the if(noupdate){} check but I'm not sure whether it is the correct way. WDYT? - Asiri

15 years

Re: [xwiki-devs] [xwiki-notifications] r25387 - in platform/xwiki-plugins/trunk: . blog blog/src blog/src/main blog/src/main/java blog/src/main/java/com blog/src/main/java/com/xpn blog/src/main/java/com/xpn/xwiki blog/src/main/java/com/xpn/xwiki/plugin blog/src/main/java/com/xpn/xwiki/plugin/blog

by Vincent Massol

On Dec 1, 2009, at 3:00 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-12-01 03:00:52 +0100 (Tue, 01 Dec 2009) > New Revision: 25387 > > Added: > platform/xwiki-plugins/trunk/blog/ > platform/xwiki-plugins/trunk/blog/pom.xml > platform/xwiki-plugins/trunk/blog/src/ > platform/xwiki-plugins/trunk/blog/src/main/ > platform/xwiki-plugins/trunk/blog/src/main/java/ > platform/xwiki-plugins/trunk/blog/src/main/java/com/ > platform/xwiki-plugins/trunk/blog/src/main/java/com/xpn/ > platform/xwiki-plugins/trunk/blog/src/main/java/com/xpn/xwiki/ > platform/xwiki-plugins/trunk/blog/src/main/java/com/xpn/xwiki/ > plugin/ > platform/xwiki-plugins/trunk/blog/src/main/java/com/xpn/xwiki/ > plugin/blog/ > platform/xwiki-plugins/trunk/blog/src/main/java/com/xpn/xwiki/ > plugin/blog/BlogPlugin.java > platform/xwiki-plugins/trunk/blog/src/main/java/com/xpn/xwiki/ > plugin/blog/BlogPluginApi.java > Modified: > platform/xwiki-plugins/trunk/pom.xml > Log: > XABLOG-63: Create a Blog Plugin and Adjust the Blog Application to > use it > Adding the blog plugin > [snip > > +/** > + * Blog Plugin is a plugin that allows to manage Blog Applications. > It allows to create, update, list and delete blog entries. > + * > + * @version $Id$ We're missing @since tags I think. Thanks -Vincent

15 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2009