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 <[email protected]> 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 <[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 > -- -- Zhaolin Feng -- www.mapbar.com -- Currahee! We stand alone together! _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
