From kai at aplteam.com  Tue Aug  5 05:23:19 2014
From: kai at aplteam.com (Kai Jaeger)
Date: Tue, 5 Aug 2014 10:23:19 +0100
Subject: [Moin-user] Problem with images
In-Reply-To: <BLU173-W29690471CC760E932C02FD9E20@phx.gbl>
References: <CAH2kyOHVnPj2MNma9OdoUD9mnjBcKoq61Y3aU19x0fqbUtptCA@mail.gmail.com>
	<BLU173-W29690471CC760E932C02FD9E20@phx.gbl>
Message-ID: <CAH2kyOGzzrXA2C8N=qh+pwDCf_Y-w0zYKucZFFh9GpLcRWQ_ZQ@mail.gmail.com>

I am using it all over the place; examples are:

http://aplwiki.com/SeeSaw

http://aplwiki.com/ScriptManager/ProjectPage  (the table-of-contents)

Kai

On Mon, Aug 4, 2014 at 11:29 PM, Emmanuel Mayssat <emayssat at epicsqt.org> wrote:
> Do you have an example of the SeeSaw macro somewhere?
> I would be interested in it.
> Note that another way to shorten the TOC is
> <<TableOfContents(3)>>
> where you limit depth.
>
> Another method is to include pages with table of contents sections.
> Here you can have a TOC for let's say level 1 and 2
> and in the included section(page), you can have a TOC for any level.
> That's a great trick!
>  Enjoy!
> --
> Emmanuel
>
>> Date: Mon, 2 Jun 2014 09:34:59 +0100
>> From: kai at aplteam.com
>> To: moin-user at lists.sourceforge.net
>> Subject: [Moin-user] Problem with images
>
>>
>> Hi there
>>
>> I have a problem with images. On the page
>>
>> http://aplwiki.com/HelpOnBasicFormatting#Images
>>
>> this code:
>>
>> || {{attachment:fish.jpg}} || {{attachment:fish.jpg}} ||
>> {{attachment:fish.jpg}} ||
>> || {{attachment:fish.jpg}} || {{attachment:fish.jpg}} ||
>> {{attachment:fish.jpg}} ||
>>
>> shows paper clips rather than the image as such, and this code:
>>
>> {{attachment:trash.bmp}}
>>
>> shows the text "trash.bmp" rather than the image.
>>
>> All the other images on that page work fine.
>>
>> What am I missing?
>>
>> Kai
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Moin-user mailing list
>> Moin-user at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/moin-user



From ajhurst at me.com  Wed Aug  6 20:38:13 2014
From: ajhurst at me.com (John Hurst)
Date: Thu, 07 Aug 2014 10:38:13 +1000
Subject: [Moin-user] Problem with images
In-Reply-To: <CAH2kyOGzzrXA2C8N=qh+pwDCf_Y-w0zYKucZFFh9GpLcRWQ_ZQ@mail.gmail.com>
References: <CAH2kyOHVnPj2MNma9OdoUD9mnjBcKoq61Y3aU19x0fqbUtptCA@mail.gmail.com>
	<BLU173-W29690471CC760E932C02FD9E20@phx.gbl>
	<CAH2kyOGzzrXA2C8N=qh+pwDCf_Y-w0zYKucZFFh9GpLcRWQ_ZQ@mail.gmail.com>
Message-ID: <7CE5400D-677A-42E9-9772-E963908BF946@me.com>

This sounds like a macro I could use, but for one thing: can the toggling be made dependent upon who is reading the page?

My application is where there is some confidential information that should only be revealed when the reader is in a certain (acl) group.  It would be good if the macro could test who the reader was, and only allow a toggle of the SeeSaw information if the reader is in that acl group.

cheers,
--John Hurst
--5 Fran Court, Glen Waverley, VIC 3150                      ~ ~~~&#:
-- ajhurst at mac.com  +61 3 9803 9346              _..___  ---____ at ___H__
--(mob 0407 569 292)                             |_____[_|_________[__]_
-- http://homepage.mac.com/ajhurst/               oo oo  oo O--O--O o=o
-- 
-- Sins are ephemeral because forgiveness is eternal


On 20140805, at 19:23, Kai Jaeger wrote:

> I am using it all over the place; examples are:
> 
> http://aplwiki.com/SeeSaw
> 
> http://aplwiki.com/ScriptManager/ProjectPage  (the table-of-contents)
> 
> Kai
> 
> On Mon, Aug 4, 2014 at 11:29 PM, Emmanuel Mayssat <emayssat at epicsqt.org> wrote:
>> Do you have an example of the SeeSaw macro somewhere?
>> I would be interested in it.
>> Note that another way to shorten the TOC is
>> <<TableOfContents(3)>>
>> where you limit depth.
>> 
>> Another method is to include pages with table of contents sections.
>> Here you can have a TOC for let's say level 1 and 2
>> and in the included section(page), you can have a TOC for any level.
>> That's a great trick!
>> Enjoy!
>> --
>> Emmanuel
>> 
>>> Date: Mon, 2 Jun 2014 09:34:59 +0100
>>> From: kai at aplteam.com
>>> To: moin-user at lists.sourceforge.net
>>> Subject: [Moin-user] Problem with images
>> 
>>> 
>>> Hi there
>>> 
>>> I have a problem with images. On the page
>>> 
>>> http://aplwiki.com/HelpOnBasicFormatting#Images
>>> 
>>> this code:
>>> 
>>> || {{attachment:fish.jpg}} || {{attachment:fish.jpg}} ||
>>> {{attachment:fish.jpg}} ||
>>> || {{attachment:fish.jpg}} || {{attachment:fish.jpg}} ||
>>> {{attachment:fish.jpg}} ||
>>> 
>>> shows paper clips rather than the image as such, and this code:
>>> 
>>> {{attachment:trash.bmp}}
>>> 
>>> shows the text "trash.bmp" rather than the image.
>>> 
>>> All the other images on that page work fine.
>>> 
>>> What am I missing?
>>> 
>>> Kai
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Moin-user mailing list
>>> Moin-user at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/moin-user
> 
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls. 
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Moin-user mailing list
> Moin-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/moin-user




From jkwight at gmail.com  Thu Aug  7 07:52:49 2014
From: jkwight at gmail.com (Jim Wight)
Date: Thu, 7 Aug 2014 12:52:49 +0100
Subject: [Moin-user] Problem with images
In-Reply-To: <7CE5400D-677A-42E9-9772-E963908BF946@me.com>
References: <CAH2kyOHVnPj2MNma9OdoUD9mnjBcKoq61Y3aU19x0fqbUtptCA@mail.gmail.com>
	<BLU173-W29690471CC760E932C02FD9E20@phx.gbl>
	<CAH2kyOGzzrXA2C8N=qh+pwDCf_Y-w0zYKucZFFh9GpLcRWQ_ZQ@mail.gmail.com>
	<7CE5400D-677A-42E9-9772-E963908BF946@me.com>
Message-ID: <CALgsy1_pjS=r9YzasAjOGaU28m2kjEpTVM1Y_NCvW=OvqmPr8g@mail.gmail.com>

On 7 August 2014 01:38, John Hurst <ajhurst at me.com> wrote:

> This sounds like a macro I could use, but for one thing: can the toggling
> be made dependent upon who is reading the page?
>
> My application is where there is some confidential information that should
> only be revealed when the reader is in a certain (acl) group.  It would be
> good if the macro could test who the reader was, and only allow a toggle of
> the SeeSaw information if the reader is in that acl group.
>

It could be done this way, putting the confidential information in a
separate acl-controlled page:

<<SeeSaw(confidential)>>
{{{#!wiki seesaw confidential
<<Include(Confidential)>>
}}}

Alternatively, if you don't want the SeeSaw link to be shown when the user
shouldn't see the information - it does nothing but toggle itself in that
situation - put the SeeSaw call in the included page, like this:

<<SeeSaw(confidential)>>
{{{#!wiki seesaw confidential
The confidential information.
}}}

The page should then be included normally, i.e. without any {{{#!wiki
wrapping.

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140807/ef35b8ba/attachment.html>

From jameswilmot2000 at gmail.com  Sun Aug 10 06:05:51 2014
From: jameswilmot2000 at gmail.com (James Wilmot)
Date: Sun, 10 Aug 2014 20:05:51 +1000
Subject: [Moin-user] Multiple file upload implementation
Message-ID: <CADi8fkcnJJxVbzzaWXiverGn4ffYF4WXdX0CUs6_CRsQv+2KgQ@mail.gmail.com>

Moin Moin!

I have hacked together a multiple file upload implementation (using
https://github.com/blueimp/jQuery-File-Upload) for my local usage on
MoinMoin 1.9.X, but I would be interested in polishing it and pushing it
upstream.

Questions:

   -  1.9.X seems to be feature stable at the moment, so would it be best
   just to develop on top of MoinMoin 2.X? I would imagine that 1.9.X would be
   out in the wild for quite some time even after the new release
   - the implementation I have is basically hacked into the
   action/AttachFile.py but doesn't change any of the backend functionality:
   it is all front end changes. Would it be best to put the feature into an
   applet like the editor?

Thanks for the excellent wiki and I hope to contribute back in other ways
in the future! (like the LDAP integration)

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140810/fa577394/attachment.html>

From jameswilmot2000 at gmail.com  Mon Aug 11 08:42:25 2014
From: jameswilmot2000 at gmail.com (James Wilmot)
Date: Mon, 11 Aug 2014 22:42:25 +1000
Subject: [Moin-user] Multiple file upload implementation
In-Reply-To: <CADuBaPCGZH22GU3G_PbRyN-TCH=KkREg4n2KPjojfWzi8pA9pg@mail.gmail.com>
References: <CADi8fkcnJJxVbzzaWXiverGn4ffYF4WXdX0CUs6_CRsQv+2KgQ@mail.gmail.com>
	<CADuBaPCGZH22GU3G_PbRyN-TCH=KkREg4n2KPjojfWzi8pA9pg@mail.gmail.com>
Message-ID: <CADi8fkfbNcAqFn2QQcWjB=n=TzR7cSoJvp8UPftmZWsb=AUgoA@mail.gmail.com>

Sorry Takeo if you deliberately meant to take this off list!


> Could it be possible to
> implement it on both?


I haven't seen the attachment functionality in MoinMoin 2.X, but if it is
anything like a 'normal' form file upload it should actually be
*relatively* trivial to shoehorn this functionality in; the plugin can
handle uploading to any normal upload handler.

If multiple file upload becomes easy, it might also be useful if
> attachments can be sorted in various ways (e.g. uploaded date, name,
> size).


This isn't something that the linked jQuery plugin could sanely address,
but I would be quite keen to look into that if the MoinMoin maintainers
directed that they were interested in this functionality. Sounds quite
useful, actually!


On Mon, Aug 11, 2014 at 10:18 PM, Takeo Katsuki <takeo.katsuki at gmail.com>
wrote:

> Hi James,
>
> Multiple file upload sounds great! Personally I would love to see this
> functionality in 1.9.X as it would benefit more people now. But
> MoinMoin people would probably want it on 2.X. Could it be possible to
> implement it on both?
>
> If multiple file upload becomes easy, it might also be useful if
> attachments can be sorted in various ways (e.g. uploaded date, name,
> size). Currently, it is pain to look for a file in a page that has a
> lot of attachments.
>
> Best,
>
> Takeo
>
> On Sun, Aug 10, 2014 at 3:05 AM, James Wilmot <jameswilmot2000 at gmail.com>
> wrote:
> > Moin Moin!
> >
> > I have hacked together a multiple file upload implementation (using
> > https://github.com/blueimp/jQuery-File-Upload) for my local usage on
> > MoinMoin 1.9.X, but I would be interested in polishing it and pushing it
> > upstream.
> >
> > Questions:
> >
> >  1.9.X seems to be feature stable at the moment, so would it be best
> just to
> > develop on top of MoinMoin 2.X? I would imagine that 1.9.X would be out
> in
> > the wild for quite some time even after the new release
> > the implementation I have is basically hacked into the
> action/AttachFile.py
> > but doesn't change any of the backend functionality: it is all front end
> > changes. Would it be best to put the feature into an applet like the
> editor?
> >
> > Thanks for the excellent wiki and I hope to contribute back in other
> ways in
> > the future! (like the LDAP integration)
> >
> > James
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Moin-user mailing list
> > Moin-user at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/moin-user
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20140811/f262a98d/attachment.html>

From tw at waldmann-edv.de  Wed Aug 13 13:23:01 2014
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Wed, 13 Aug 2014 19:23:01 +0200
Subject: [Moin-user] Multiple file upload implementation
In-Reply-To: <CADi8fkcnJJxVbzzaWXiverGn4ffYF4WXdX0CUs6_CRsQv+2KgQ@mail.gmail.com>
References: <CADi8fkcnJJxVbzzaWXiverGn4ffYF4WXdX0CUs6_CRsQv+2KgQ@mail.gmail.com>
Message-ID: <53EB9EF5.10804@waldmann-edv.de>



On 08/10/2014 12:05 PM, James Wilmot wrote:
> Moin Moin!
> 
> I have hacked together a multiple file upload implementation
> (using https://github.com/blueimp/jQuery-File-Upload)

Cool, I used the same stuff for another project (bepasty on github).

> for my local usage on MoinMoin 1.9.X, but I would be interested in
> polishing it and pushing it upstream.
> 
> Questions:
> 
> -  1.9.X seems to be feature stable at the moment,

Yes, whether your change is acceptable for inclusion into 1.9 depends
a lot on the impact it has on existing code / functionality. Also,
some admins or distribution packagers might want to have it optional
and off-by-default.

> just to develop on top of MoinMoin 2.X?

moin2 is preferable for new features. And IIRC we already have
multi-file-upload there, I don't remember whether it was with that lib
or some other one, though. Try throwing stuff onto the index page of
moin2.

> - the implementation I have is basically hacked into the 
> action/AttachFile.py but doesn't change any of the backend
> functionality: it is all front end changes. Would it be best to put
> the feature into an applet like the editor?

I think I can give better advice if you just put the stuff on
codereview.appspot.com and add me as a reviewer there.

> Thanks for the excellent wiki and I hope to contribute back in
> other ways in the future! (like the LDAP integration)

You're welcome! And we would definitely like you trying moin2 and
hacking it for usability. :)

BTW, in next 1.9 release, there are some minor changes to deal with
(==delete, move) "multiple attachments" already, see repo.

BTW, if you use IRC, join us on #moin-dev on freenode.

Cheers,

Thomas



From tw at waldmann-edv.de  Fri Aug 22 06:20:46 2014
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Fri, 22 Aug 2014 12:20:46 +0200
Subject: [Moin-user] release candidate for 1.9.8
Message-ID: <53F7197E.2060902@waldmann-edv.de>

Moin :)

Just wanted to tell that I've uploaded a RC for 1.9.8 so it can get more
testing.

It would be nice if some of you would download it, test it and provide
feedback. I have the code running on moinmo.in for a while, but feedback
from different installations is always good.

There are some new features in it as well as quite some bugfixes.

Change-Log:
http://hg.moinmo.in/moin/1.9/file/fde5fea5986a/docs/CHANGES

Download:
http://static.moinmo.in/files/moin-1.9.8.tar.gz

$ sha256sum moin-1.9.8.tar.gz
1657ebaf6034aae3c5d275e4d90a5452789a97d5031b641ad77b3e94228a5a41
moin-1.9.8.tar.gz

Cheers,

Thomas



From lists at sumpfralle.de  Mon Aug 25 20:01:10 2014
From: lists at sumpfralle.de (Lars Kruse)
Date: Tue, 26 Aug 2014 02:01:10 +0200
Subject: [Moin-user] Plugins: recommendations for accessible local directory?
Message-ID: <20140826020110.19a2514c@erker.lan>

Hi,

recently I upgraded the VisualSiteMap action [1] for moinmoin v1.9 and today I
added the HoverCraft action [2].
In both cases an external application is called in order to create one or more
files locally:
* VisualSiteMap: dot/neato/... creates an svg file
* HoverCraft: a directory containing an html file and some more resource files
  is created

To be of any use, these files need to be accessible via a URL.

Thus both actions are currently configured with two pieces of information:
1) a local file path
2) a URL which is mapped to the above path (via a webserver?)

The actions call their respective external application and put their result
into the above local directory. The URL of these files is delivered/embedded to
the user.

This approach feels a bit clumsy, since the webserver requires manual
configuration (mapping the directory to a URL) for each action separately, e.g.:

  AliasMatch /wikis/([^/]+)/_hovercraft-cache/(.*)$ /var/cache/moin/HoverCraft/$1/$2

(suitable for the HoverCraft action and for multiple wikis via farmconfig)

Additionally the above approach ignores any ACL restrictions - but I could live
wih that.


Since at least the two above actions require this directory/URL mapping
(separated for each wiki), I could imagine that maybe MoinMoin already includes
something similar?
Or is the preferred approach to turn the created files into attachments of the
respective wiki page? This could work for VisualSiteMap but would be quite messy
for HoverCraft since it creates multiple files.

Please share your opinions!

Cheers,
Lars


[1] http://moinmo.in/ActionMarket/VisualSiteMap
[2] http://moinmo.in/ActionMarket/HoverCraft



From paul at boddie.org.uk  Tue Aug 26 12:51:26 2014
From: paul at boddie.org.uk (Paul Boddie)
Date: Tue, 26 Aug 2014 18:51:26 +0200
Subject: [Moin-user] Plugins: recommendations for accessible local
	directory?
In-Reply-To: <20140826020110.19a2514c@erker.lan>
References: <20140826020110.19a2514c@erker.lan>
Message-ID: <201408261851.27176.paul@boddie.org.uk>

On Tuesday 26. August 2014 02.01.10 Lars Kruse wrote:
> 
> recently I upgraded the VisualSiteMap action [1] for moinmoin v1.9 and
> today I added the HoverCraft action [2].
> In both cases an external application is called in order to create one or
> more files locally:
> * VisualSiteMap: dot/neato/... creates an svg file
> * HoverCraft: a directory containing an html file and some more resource
> files is created
> 
> To be of any use, these files need to be accessible via a URL.

If these things really need to create actual files, or if it's easier for them 
to be made to create files instead of just producing data on demand, then you 
could potentially use either the attachment or caching APIs in Moin, and then 
Moin could be made to serve things from the attachment or cache areas in the 
filesystem.

I can think of two things I've had something to do with that uses these APIs:

https://moinmo.in/ParserMarket/graphviz (uses the attachment API)
https://moinmo.in/ActionMarket/ExportPDF (uses the caching API)

Both of these invoke other processes and collect output directly from those 
processes instead of letting them write to files. This is arguably more 
elegant because you don't have to clean up random files generated by tools and 
can choose whether to cache the output or to just send it to the browser 
directly.

> Thus both actions are currently configured with two pieces of information:
> 1) a local file path
> 2) a URL which is mapped to the above path (via a webserver?)

You can use URLs which invoke actions to get cached or attached content, but 
you'll need to make sure that any URLs embedded in any generated data are 
suitable for subsequently requesting things from Moin. I seem to recall Moin 
supporting a nicer way of requesting attachments than explicitly invoking the 
AttachFile action, so you might even have an easier job ahead of you if you 
use attachments.

> The actions call their respective external application and put their result
> into the above local directory. The URL of these files is
> delivered/embedded to the user.
> 
> This approach feels a bit clumsy, since the webserver requires manual
> configuration (mapping the directory to a URL) for each action separately,
> e.g.:
> 
>   AliasMatch /wikis/([^/]+)/_hovercraft-cache/(.*)$
> /var/cache/moin/HoverCraft/$1/$2
> 
> (suitable for the HoverCraft action and for multiple wikis via farmconfig)
> 
> Additionally the above approach ignores any ACL restrictions - but I could
> live wih that.

It's always worth remembering ACLs when developing actions to obtain data from 
the cache or associated with a page.

> Since at least the two above actions require this directory/URL mapping
> (separated for each wiki), I could imagine that maybe MoinMoin already
> includes something similar?
> Or is the preferred approach to turn the created files into attachments of
> the respective wiki page? This could work for VisualSiteMap but would be
> quite messy for HoverCraft since it creates multiple files.

I can't remember if there are any nice ways of creating cached bundles of 
files, presumably within their own subdirectories of a cache directory set up 
for this purpose, but even if the API isn't that helpful you could still write 
the necessary code to deal with creating such subdirectories: you'd only be 
getting the appropriate filesystem path from Moin and then appending the 
appropriate details in order to construct a specific path for any given 
purpose. Just be careful to sanitise paths in order to avoid data leakage from 
(or contamination of) the wider filesystem.

Hope this helps!

Paul