[pmwiki-users] new UploadsMarkup recipe

ThomasP pmwikidev at sigproc.de
Fri Dec 14 07:35:10 CST 2007


On Fri, December 14, 2007 10:02 am, Eemeli Aro wrote:
> I'm a little confused. How does this add to the functionality that
> already exists with the Attach: markup? With the form
>
> Attach:Group/file.txt
> or
> Attach:Group/Page/file.txt
>
> you can already refer to the attachments associated with a different
> group and/or page. What your UploadsMarkup also does is provide a way
> to use the same syntax to refer to pages in the uploads root or the
> subdirectories of group/page directories. However, I'm still not
> seeing the benefit of this, as you can't use PmWiki to place files in
> those directories. Am I missing something?
>
> eemeli
>

To be honest, I have to discover that I somewhat carelessly misestimated
the benefit of this markup. In particular you are right that the
addressing in other pages/groups is already possible right now.

The special case where an alternative markup other than Attach: would have
its application is when multiple UploadPrefixFmt settings are used, e.g. a
special one in a certain group via a group config. This was so in the case
that spawned the discussion. Then it is not possible with the current
Attach: markup to refer to attachments in another group in which
attachments were saved using a second UploadPrefixFmt. Ex.:

Group B has a special UploadPrefix, say /$Group/$Name, whereas the rest of
the wiki has /$Group. Consider attachments saved in group B for some page
X. They are stored in uploads/B/X/. If one wants to refer to these files
from another "normal" page A in the wiki,

Attach:B/X/myfile.txt

will not help as it is mapped to the path uploads/B/myfile.txt via the
global UploadPrefixFmt setting(*) used when interpreting markup in page A.
Thus then a "free" referencing mechanism targeting the actual storage
location rather than a page with associated upload dir would help.

I have to admit though again that the solution I have intended to produce
is not actually a solution, as indeed the mechanisms doing the actual
download or upload are not seeing the exact path information. It is by far
more to it than just adapting the link making / resolution process. I
would initially have planned a markup that enables saving to and
retrieving from anywhere, bridging possible UploadPrefixFmt differences at
least by using absolute paths, but it will take probably an unjustified
amount of effort to reach this. (considering the specialty of the problem)

Thomas

(*) This makes a problem only if the file exists in the B/X/myfile.txt
location, as it will not be searched for there (looking deeply into the
current code of scripts/upload.php). The file saving part is actually not
concerned.





More information about the pmwiki-users mailing list