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 <[email protected]> > 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 >> _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
