Re: [xwiki-devs] Introduce new tempresource action

Vincent: I know I can't. But I just want to know if someone else have some knowledge of open source alternatives. If so, the integration is possible then.

On Tue, Dec 15, 2009 at 12:34 AM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: > Hi Zhalin, > > On Dec 14, 2009, at 5:21 PM, Zhaolin Feng wrote: > >> Hi, Vincent: >> >> Please don't be mad at me. > > :) > >> I think it's a cool trick. But I don't think >> rendering ascii graph into bitmap will add too much information. > > The mail wasn't about Ditaa. It was about introducing a temresource > action. > >> And ordinary users will still find it hard to use. >> >> How about embedding a AJAX or flash based graphics editor? I know >> there are >> some good ones, but I don't know whether there are some open source >> alternatives. >> >> Here are some live demos: >> >> http://www.lucidchart.com/documents/demo >> http://www.drawanywhere.com/demo.aspx >> >> And the best one: http://www.gliffy.com/ which requires an account. > > Yes Gliffy is great. I'd love to have it. When can you start > implementing the integration? :) > > Thanks > -Vincent > >> On Mon, Dec 7, 2009 at 4:11 AM, Vincent Massol &lt;vincent(a)massol.net&gt; >> wrote: >> >>> Hi, >>> >>> Part I >>> ===== >>> >>> I've started implementing a Ditaa Macro over the weekend ( >>> http://ditaa.sourceforge.net/ >>> ) but we need an Action to return the Ditaa-generated image file. >>> For the chart macro we're using the charting action but I think we >>> can >>> make this generic and instead introduce a tmp (or temp or >>> tmpresource >>> or ...) action instead that would return any resource located in >>> the >>> xwiki temporary directory. >>> >>> For ex: >>> /xwiki/bin/tmp/SomeResource >>> >>> would return SomeResource found in >>> container.getApplicationContext().getTemporaryDirectory(). >>> >>> Part II >>> ===== >>> >>> The only thing to be careful about is to not be able to read what's >>> for another user and for which you don't have access to see it. For >>> example an image generated by the chart macro for a page for which >>> the >>> user doesn't have view rights. This can be partially solved by >>> ensuring that file names include a generated token. However the >>> pb is >>> that this token cannot be unique since, for ex, generated image >>> need >>> to be shared to anyone having the rights to view a page. >>> >>> <brainstomring mode> >>> >>> A solution I see would be to include the "rights" to check + the >>> full >>> page name in the URL, in addition to the resource. For example: >>> >>> /xwiki/bin/tmp/view/wiki:Space.Page/SomeResource >>> >>> A more generic solution would be to add a notion of Check Handler, >>> i.e. code that would perform the check. For example in the previous >>> solution it's not possible to check for 2 permissions, nor any >>> complex >>> scheme. This would mean something like: >>> >>> /xwiki/bin/tmp/<check handler name>/<resource name>?<check params> >>> >>> Ex: /xwiki/bin/tmp/simple/SomeResource? >>> checkPermission="view"&checkDocument="wiki:Space.Page" >>> >>> Implementation: A component with a role hint of "simple" would be >>> looked-up and the check logic delegated to it. >>> >>> However someone could use a some check for a resource that wasn't >>> meant to be used for that resource. >>> >>> Thus the check and its params should probably instead be included >>> in >>> the resource name with some algorithm instead. Thus the solution >>> maybe >>> to have a high level API to create a resource name and that API >>> would >>> take a Check Handler hint + some arbitrary params and that API >>> would >>> generate a resource name with these added. For ex something like:: >>> "SomeResource-simple-view-wiki:Space.Page" (or any other format). >>> >>> Another solution would be to follow a completely different >>> direction >>> and for example to introduce a new XDOM representation for a TMP- >>> image, i.e. in addition to URLImage and DocumentImage, to add a >>> TemporaryImage implementation. >>> >>> </brainstomring mode> >>> >>> WDYT about these 2 ideas and especially about Part I since I would >>> need that sooner rather than later to implement the Ditaa macro, >>> and >>> Part II is already a problem today. >>> >>> Thanks >>> -Vincent