On Fri, Sep 24, 2010 at 15:37, Anca Luca <[email protected]> wrote: > Hi all, > > On 09/22/2010 02:47 PM, Sergiu Dumitriu wrote: >> On 09/22/2010 12:31 PM, Marius Dumitru Florea wrote: >>> Hi devs, >>> >>> I'm going to create a macro for previewing office attachments. It's main >>> usage will be: >>> >>> {{officepreview attachment="presentation.ppt" filterStyles="true"/}} >>> >>> "officepreview" is a bit long for a macro name. "preview" is shorter but >>> is too generic and thus can be confusing. "preview" could be the name of >>> a more generic macro that previews any type of attachment, based on its >>> mime type (so not just office documents). >>> >>> "attachment" is the only required parameter. It is also a bit long, but >>> "file", which is shorter, is confusing. Some users might try to preview >>> office documents from their file system or from the web. >>> >>> "filterStyles" is optional, and defaults to false. >> >> I take it that the current implementation outputs HTML, right? I'd like >> to have a preview mode which generates small images instead, snapshots >> of each page/slide, placed one after another horizontally, in a div with >> a scrollbar. Could it be done? >> >>> The office preview macro will be just a wrapper for the office preview >>> script service. This means no decorations (e.g. borders, headings, etc.) >>> will be added around the output of the script service: >>> >>> {{velocity}} >>> {{html}} >>> $services.officepreview.preview($attachmentReference, $filterStyles) >>> {{/html}} >>> {{/velocity}} >>> >>> I'm not sure if the office preview macro should be a wiki macro or a >>> Java macro. One disadvantage for wiki macros is >>> http://jira.xwiki.org/jira/browse/XWIKI-4262 . This means that the >>> attachment string reference must be resolve before calling the office >>> preview script service. Currently there's no clean way to resolve a >>> reference relative to a given document in velocity so I would have to >>> use groovy which raises programming rights issue. Alternative we can >>> extend the >>> http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-model/src/main/java/org/xwiki/model/internal/scripting/ModelScriptService.java >>> . >>> >>> There's nothing to customize so the power of wiki macros wouldn't be >>> used. You can create a wiki macro that wraps the office preview macro >>> and add decorations specific to your needs. >>> >>> One the other hand, the advantages of a Java macro are not significant >>> either because the macro is just a simple wrapper for the office preview >>> script service. >>> >>> WDYT? >> >> +1 for java macro. One advantage is that it will be usable nested inside >> scripting macros as well (otherwise the velocity macro inside will >> prevent it). > > If I remember correctly this was fixed, wiki macros should be a special > case and allow scripting macro inside scripting macro, otherwise > wikimacros will be unusable on an "if" branch.
Yes it's fixed. See http://jira.xwiki.org/jira/browse/XWIKI-5435. > > Otherwise, I think I would prefer wikimacro, for this case, since it's > more like a "shortcut" (instead of writing {{velocity}}{{html}}...., one > just writes {{officepreview ...) I don't like that much the idea of > having this kind of shortcuts in the java macros, but I don't have a > strong opinion. > > Thanks, > Anca > >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
