xwiki-devs December 2008

xwiki-devs@xwiki.org

30 participants
92 discussions

[xwiki-devs] [VOTE][UI] WYSIWYG Image dialogs

by Jean-Vincent Drean

Hi XWikiers, I've made mockups for the WYSIWYG Image dialogs, you can see them at : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HImage Votes for internal image insertion : 1) Image size ------------------ In the mockup you can see a dropdown allowing to set some predefined sizes to the image (inspired by google docs). We could rely on the browser's image resizing feature for this and drop this setting. I'm in favor of keeping it (see my votes below) since it allow to keep size consistency between multiple images (screenshots for example) in the same page. Also, IE and FF have this resizing feature but we can't assume that it'll be the same for all the browsers we will target in the future. 2) Image size option --------------------------- a) Allow to edit only the image width (guarantee that the image width/height ratio won't be affected by the resize). b) Allow to edit both image width and height. 3) Text flow --------------- I think it's a must have but since it'll rely on a touchy parameter I prefer that we vote for it. Generated wiki syntax example : [[image:awsome.jpg||style="float:right"]] Notes : - for the moment using this will cause issues with titles, see : http://www.jean-vincent.org/xwiki/bin/view/Main/Image - I'm not sure that we'll be able to combine position center + text flow. 4) Preview -------------- I've put an image preview in the mockup, we've multiple choices: a) Drop it since it makes the dialog heavy. a) Keep it stupid simple, the image is represented by a placeholder and the 6 possible states are "prerecorded" (could be images). d) Make it an advanced preview, the image is the selected image, the preview takes the size of the image into account (by calculating what the selected size would look like compared to the page content in a predefined resolution, like 1024x768). Votes for external image insertion : 5) Number of wizard steps ----------------------------------- Like for the link insertion dialogs we have a major difference between internal and external stuff. We could : a) Have 2 steps to be consistent with the internal insertion. First step : image URL, second step : image options. b) Ease the edit work and have all the settings in the same screen, this is how I've presented it in the mockup. My votes : 1) +1 2) +1 for a) 3) +1 4) +1 for d) if possible 5) +1 for b) Thanks, JV.

15 years, 9 months

[xwiki-devs] [VOTE][UI] WYSIWYG Link dialogs

by Jean-Vincent Drean

Hi, Now that we have agreed on the "wiki explorer" thing I've updated the link proposal accordingly. The mockups are available at : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HLink I've tried to spot all the items that we'd want to discuss but I may have forgotten some of them, feel free to raise new discussions. Votes for internal links : 1) Flyover ------------- Do we want to be able to easily set the link title ? Wiki syntax : [[current selection>>Main.WebHome||title="flyover"]] Votes for external links : 2) Number of wizard steps ----------------------------------- We have a major difference between external and internal links, pasting a URL doesn't require a fancy editor. We could : a) Have 2 steps to be consistent with the internal insertion. First step : link URL, second step : link options. b) Ease the edit work and have all the settings in the same screen (URL + options), this is how I've presented it in the mockup. My votes : 1) +1 2) +1 for b) JV.

15 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r14570 - in platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki: . web

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-12-05 12:29:12 +0100 (Fri, 05 Dec 2008) > New Revision: 14570 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/XWikiRequestProcessor.java > Log: > XWIKI-2824: Support multiwiki using path urls and not host urls > * make action name for servlet configurable ("wiki" by default) > > + > + private String getProperty(String propertyKey, String defaultValue) > + { > + if (this.config == null) { > + // Make XWikiRequestProcessor own configuration loader since XWiki of Configuration component are not > + // initialized at this time This part should be synchronized, to prevent parallel initialization. Or, load it in a constructor or static block (making the config static, also). You could also comment this setting in xwiki.cfg.vm -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r14565 - in platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki: api doc

by Vincent Massol

On Dec 5, 2008, at 7:55 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-12-05 07:55:30 +0100 (Fri, 05 Dec 2008) > New Revision: 14565 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ > Document.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java > Log: > XWIKI-2549: Make Document.addAttachment public > Done. > > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > api/Document.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ > Document.java 2008-12-05 04:30:58 UTC (rev 14564) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ > Document.java 2008-12-05 06:55:30 UTC (rev 14565) > @@ -20,7 +20,6 @@ > */ > package com.xpn.xwiki.api; > > -import java.io.ByteArrayOutputStream; > import java.io.IOException; > import java.io.InputStream; > import java.util.ArrayList; > @@ -32,7 +31,6 @@ > import java.util.Vector; > > import org.apache.commons.fileupload.FileItem; > -import org.apache.commons.io.IOUtils; > import org.apache.commons.lang.StringUtils; > import org.suigeneris.jrcs.diff.DifferentiationFailedException; > import org.suigeneris.jrcs.rcs.Version; > @@ -1721,7 +1719,7 @@ > filename = filename.replaceAll("\\+", " "); > > if ((data != null) && (data.length > 0)) { > - XWikiAttachment attachment = > addAttachment(filename, data); > + XWikiAttachment attachment = > this.doc.addAttachment(filename, data, getXWikiContext()); > getDoc().saveAttachmentContent(attachment, > getXWikiContext()); > // commenting because this was already done by > addAttachment > // getDoc().getAttachmentList().add(attachment); > @@ -1736,39 +1734,26 @@ > return nb; > } > > - protected XWikiAttachment addAttachment(String fileName, > InputStream iStream) throws XWikiException, IOException > + public Attachment addAttachment(String fileName, InputStream > iStream) > { > - ByteArrayOutputStream bAOut = new ByteArrayOutputStream(); > - IOUtils.copy(iStream, bAOut); > - return addAttachment(fileName, bAOut.toByteArray()); > + try { > + return new Attachment(this, > this.doc.addAttachment(fileName, iStream, getXWikiContext()), > getXWikiContext()); > + } catch (XWikiException e) { > + // TODO Log the error and let the user know about it > + } catch (IOException e) { > + // TODO Log the error and let the user know about it I don't like this... Don't we have a solution to handle it in a better way? With the current solution scripts calling this method need to check for null and take action if null which I'm pretty sure none care about so it'll silently fail. The best current solution is probably to store the result in the "error" variable in the Velocity context (we have a variable for this) and modify a main template to check for errors in page execution and if there are redirect to an error page printing them. The script should then be able to do a check for null itself and have the ability to clear the error if it can handle it gracefully so that the error page doesn't appear for the user. WDYT? [snip] Thanks -Vincent

15 years, 9 months

[xwiki-devs] Fwd: [ANNOUNCE] Apache Velocity 1.6

by Vincent Massol

fyi. Seems like we can now refactor our ubespector to use Sergiu's patch that was committed in Velocity 1.6. Well done Sergiu :) Also this is very intriguing: "macro libraries to be programatically included when calling template.merge(...)" -Vincent Begin forwarded message: > From: "Nathan Bubna" <nbubna(a)apache.org> > Date: December 3, 2008 7:04:03 AM CEST > To: announce(a)apache.org, announcements(a)jakarta.apache.org, dev(a)velocity.apache.org > , user(a)velocity.apache.org > Subject: [ANNOUNCE] Apache Velocity 1.6 > > The Apache Velocity Team announces the immediate availability of the > of Apache Velocity Engine 1.6. This release is fully compatible with > the previous release and includes significant improvements in > performance, stability and features. > > Apache Velocity is well-known in the Java field as a lightweight, > easy-to-use templating library for creating dynamic web sites and > performing other text-generation tasks. > > Much work in this release has gone to making significant improvements > in the memory usage and speed of Velocity. Apart from this, a number > of small parser bugs were fixed, tempate/line/column information in > error messages has been corrected and made consistent, and many new > features were added. Many of the latter are listed below: > > * There are three new directives: > - #evaluate takes a single string of VTL as an argument and renders > it. > - #define is a cousin of #macro, that lets define a reference that > represents the body of the directive, which is then evaluated when the > reference is used. > - #break lets you exit a #foreach loop early. > > * There are reflection improvements: > - You may now call JDK 1.5 vararg methods on your tools and other > references with variable arguments. > - You can put a static utility class directly into the context and > be able to call its methods; no instance necessary. (e.g. > context.put("Math", java.util.Math.class)) > - If you have a reference that is an array, you can now call > fixed-length list methods on it. (e.g. $array.size() and > $array.get($index) ) > - There is now support for chaining and linking Uberspect > implementations to simplify custom introspection. > > * The underlying Velocimacro code has been refactored to allow: > - Much, much better performance than Velocity 1.5 > - #parse( 'mymacros.vm' ) to work as expected!! > - macro libraries to be programatically included when calling > template.merge(...) > - users to configure a velocimacro.max.depth property (to limit > recursion et al) > > * CommonsLogLogChute and ServletLogChute are now available without > including VelocityTools > > * The StringResourceLoader has undergone major refactoring to make it > much more user-friendly and flexible. > > * There is now an automatic $velocityHasNext reference in #foreach > loops > > * You can now configure the connection timeout for URLResourceLoader > (JDK 1.5+ only) > > Documentation Velocity 1.6 can be found here: > http://velocity.apache.org/engine/releases/velocity-1.6/ > > The change log is here: > http://velocity.apache.org/engine/releases/velocity-1.6/changes-report.html > > Apache Velocity 1.6 can be downloaded here: > http://velocity.apache.org/download.cgi > > For the Apache Velocity Team > Nathan Bubna

15 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r14548 - in platform: core/trunk/xwiki-core/src/main/java/com/xpn/xwiki web/trunk/standard/src/main/webapp/WEB-INF

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-12-04 18:31:07 +0100 (Thu, 04 Dec 2008) > New Revision: 14548 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > platform/web/trunk/standard/src/main/webapp/WEB-INF/web.xml > Log: > XWIKI-2824: Support multiwiki using path urls and not host urls > * fix action name > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > + String[] vhi = uri.split("/"); > + if (vhi.length > 2 && vhi[2].equals("wiki")) { > + host = vhi[3]; > + } > } This is wrong. This will break http://www.boston.com/yourtown/wiki/Newton/ /wiki/ should be configurable. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 9 months

by Thomas Mortagne

On Fri, Dec 5, 2008 at 4:20 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > tmortagne (SVN) wrote: >> Author: tmortagne >> Date: 2008-12-04 14:00:49 +0100 (Thu, 04 Dec 2008) >> New Revision: 14542 >> >> Log: >> XWIKI-2824: Support multiwiki using path urls and not host urls >> >> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java >> =================================================================== >> + public String getServletPath(String wikiName, XWikiContext context) >> + { >> + // unless we are in virtual wiki path mode we should return null >> + if (!context.getMainXWiki().equalsIgnoreCase(wikiName) && "1".equals(Param("xwiki.virtual.usepath", "0"))) { >> + String database = context.getDatabase(); >> + try { >> + context.setDatabase(context.getMainXWiki()); >> + XWikiDocument doc = getDocument(getServerWikiPage(wikiName), context); >> + BaseObject serverobject = doc.getObject("XWiki.XWikiServerClass"); >> + if (serverobject != null) { >> + String server = serverobject.getStringValue("server"); >> + return "wiki/" + server + "/"; >> + } >> + } catch (Exception e) { >> + LOG.error("Failed to get URL for provided wiki [" + wikiName + "]", e); >> + } finally { >> + context.setDatabase(database); >> + } >> + } >> + > > This means that only struts is accepted for this kind of virtual > servers? What about xmlrpc, webdav, wysiwg, gwt, and the incoming REST? It's really difficult to have a full support of url based multiwiki with the current tricky way of handling URLs (it's already pretty difficult to support only struts without breaking anything...). We really need the unique component based entry point we discussed and get rid of struts. > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

15 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r14553 - in platform/web/trunk/wysiwyg/src/main: java/com/xpn/xwiki/wysiwyg/client java/com/xpn/xwiki/wysiwyg/client/editor java/com/xpn/xwiki/wysiwyg/client/plugin/image java/com/xpn/xwiki/wysiwyg/client/plugin/image/ui java/com/xpn/xwiki/wysiwyg/server resources/com/xpn/xwiki/wysiwyg/client/editor resources/com/xpn/xwiki/wysiwyg/public

by Sergiu Dumitriu

Marius Dumitru Florea wrote: > Sorry. I'm keeping only the important part this time. > > Marius Dumitru Florea wrote: >> Look at the end, >> >> lucaa (SVN) wrote: >>> Author: lucaa >>> Date: 2008-12-04 21:46:47 +0100 (Thu, 04 Dec 2008) >>> New Revision: 14553 >>> > > [snip] > >>> -div.clear { >>> +.xImagePreviewSelected img { >>> + border: solid 2px #FFA500; >>> +} >>> + >>> +div.clearfloats { >> You either use the clearfloats class from the current skin or make the >> selector specific to the image plugin. >> >>> clear: both; >>> + display: none; >> Does this work? From what I know if you set the display to none the DOM >> elements matched by the selector are not displayed thus they are not >> part of the flow thus they don't affect the flow. >> It doesn't. As you said, display: none makes clear to be ignored. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 9 months

by Vincent Massol

Hi Marius, On Dec 5, 2008, at 8:24 AM, Marius Dumitru Florea wrote: > Look at the end, I don't see anything at the end. I think a possibly better way is to snip whatever is not relevant to your answer with [snip] :) > lucaa (SVN) wrote: >> Author: lucaa >> Date: 2008-12-04 21:46:47 +0100 (Thu, 04 Dec 2008) >> New Revision: 14553 >> >> Added: >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/plugin/image/ImageConfig.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/plugin/image/ui/FileUploadForm.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/plugin/image/ui/ImageParametersPanel.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/plugin/image/ui/ImageSelector.java >> Removed: >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/plugin/image/ui/HasImage.java >> Modified: >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/WysiwygService.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/WysiwygServiceAsync.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/WysiwygServiceAsyncCacheProxy.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/editor/Strings.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/plugin/image/ImageHTMLGenerator.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/plugin/image/ImagePlugin.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/plugin/image/ui/ImageDialog.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> client/plugin/image/ui/ImagePreviewWidget.java >> platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ >> server/DefaultWysiwygService.java >> platform/web/trunk/wysiwyg/src/main/resources/com/xpn/xwiki/ >> wysiwyg/client/editor/Strings.properties >> platform/web/trunk/wysiwyg/src/main/resources/com/xpn/xwiki/ >> wysiwyg/public/Wysiwyg.css >> Log: >> XWIKI-2875: Allow to add images in the document >> * Added mechanism for image parameter setting: size, alt text, >> positioning >> * Improved UI, browser support, image data model [snip] Thanks -Vincent

15 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r14542 - in platform: core/trunk/xwiki-core/src/main/java/com/xpn/xwiki core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/xwiki core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/test core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/web skins/trunk/albatross/src/main/resources/albatross web/trunk/standard/src/main/webapp web/trunk/standard/src/main/weba

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-12-04 14:00:49 +0100 (Thu, 04 Dec 2008) > New Revision: 14542 > > Log: > XWIKI-2824: Support multiwiki using path urls and not host urls > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > =================================================================== > + public String getServletPath(String wikiName, XWikiContext context) > + { > + // unless we are in virtual wiki path mode we should return null > + if (!context.getMainXWiki().equalsIgnoreCase(wikiName) && "1".equals(Param("xwiki.virtual.usepath", "0"))) { > + String database = context.getDatabase(); > + try { > + context.setDatabase(context.getMainXWiki()); > + XWikiDocument doc = getDocument(getServerWikiPage(wikiName), context); > + BaseObject serverobject = doc.getObject("XWiki.XWikiServerClass"); > + if (serverobject != null) { > + String server = serverobject.getStringValue("server"); > + return "wiki/" + server + "/"; > + } > + } catch (Exception e) { > + LOG.error("Failed to get URL for provided wiki [" + wikiName + "]", e); > + } finally { > + context.setDatabase(database); > + } > + } > + This means that only struts is accepted for this kind of virtual servers? What about xmlrpc, webdav, wysiwg, gwt, and the incoming REST? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 9 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2008