Virtual Folders / Sections (VFS)

Resolving between the uploaded documents with coded file names and their respective original file names achieved by respetive database records, for example pair of original and coded file names record.

During assessment of that simplified solution and inclusion of desirable qualities as security, diversity, versatility, easiness was born the Virtual Folders / Sections idea (VFS). Which, in current implementation, composed by two tables.

First table, where, each record define the Virtual Folder / Section parameters which linked to module ID and combination of VFS name must to be unique.

And a second table where is linked uploaded document original file name with coded file name and additionaly the ID of Virtual Folder / Section record to which uploaded document belongs.

Obviously can to be added to first table any imaginable parameters (if not all) we want to diversify the uploader environment. So each virtual folder / section can be consisted of totaly diffrent combination of available parameters, as for example, diffrent destination folder, resizing, watermark( different text or image, position, fonts, colors etc.) and any other uploader parameter we want to include.

Current implementation include destination path and watermark options and ready to include any other parameter we want.

Additionally, in current implementation for second table, are added auxiliary fields, the title and description, for each uploaded document.

Which are can to be added manually for each uploaded document directly in respective fields.

Or can use common title and description messages plus some, file related info, to supplay these auxiliary automatically by the respective device of adjustable unified auxiliary messages - "Setup auxiliary fields panel" accessible from "Options panel" button.

Beauty of VFS conception lies in fact that every VFS record can to be a totally different uploader environment. Different "Uplo" module.

  

Lets to see on example benefits of VFS.

In most business models the users uploads, desirable, to be distinct by number of thematics, business model specifics.

It is highly desirable to diversify and altogether simplify the upload function, get fill of personal care of users uploaded documents.

For example:

Translation bureau needs uploaded documents to be translated in a number of languages and users to be able to select between the languages they want to be translated their documents.

So what offers the VFS solution of Uplo module to particular example of Translation bureau?

So, Translation bureau, in our example, will needs only one upload module with demanded number of virtual folders / sections, each for language the documents translated in, switchable from the front end from the final users. Where benefits are:

a) Each registered user can to choose virtual folder / section where he / she wants to upload its documents. Additionally can to be greatly guided and assisted by description field which describe purpose of particular virtual folder.

b) Documents going in user personal folder - increased uploaded documents security.

c) Each user can to see and access only documents he / she uploaded in each Virtual folder / section.

d) If not used some kind of feedback to confirm receiving of uploaded documents success (can to download from demo page), can to use auxiliary fields to send confirmation email.

e) Virtual folders / sections support centralised serving of uploaded documents by a script. Additional layer of security plus easy integration.

Few words more about VFS correct use.

Its highly desirable the name of VFS to be related to its content and VFS description field to complement and clarify the VFS name beyond any ambiguity, as poorly description and unmutched VFS name field can bring negative impact, as your customers will have no clue what document to upload in what section. Its of crucial usability for your site users / customers and finally for your business.

When a module is removed all of its net of addresses created when it been in use, remains in the system. However from module back-end can to be removed, some or all, of its virtual folders / sections explicitly. That net of addresses, created by that particular module, as all of records created by all Uplo modules when being in use can to be used independently of presence of Uplo modules that creates them.

Access the uploaded document

When module is active, then to access any of its upload documents in currently active section simple need to know original file name of document and module ID in URL pattern which uses the access ig.php script.

Below, to adopt more easily the use of access script lets see on an example the URL pattern used this script:

http://j-ext.net/ig.php?i=image.jpg&m=107&v=Sea images

Where:

          ig.php is script about and free you from the mess of various paths related to various containers/folders and permissions used. And only parameters you are needed are shown below, based on the URL pattern example above.

          1. Use of original file name, in parameter (i=image.jpg).

          2. Particular module ID in parameter (m=107).

          3. In cases when you want to use virtual folders/sections other than the current one, which is in use by module then mast to supply that virtual folder/section name in parameter (v=Sea images).

So, in short, virtual folders /sections evolve an advanced uploader device such as Upload module to versatile device able to provide elegant solution to any business model where needed modern upload function.