[pmwiki-users] possible fix for wikiform issue

[John Rankin]

On Thursday, 25 October 2007 4:55 AM, Asociacion de Robotica <emarte at aiolosrd.com> wrote:
>Hi Jonh Once again.,
>
><snip>
>
>#3:
>Here comes the problem. Basically here is where everybody brake down in
>their projects. In previous discussions I have read about implemnetatios
>such of creating a gruoup for every issue/Project, having a single page for
>every issue or task using the project as a field then using the field
>project for listing. Also discussion about pagelist and fpara as a
>superwikilist markup. 
>
>I commented about using a prefix or suffix for helping in not creating so
>many groups in a single implementation.
>
>Well basically I believe the main problem here is that everybody has a bunch
>of Wikiforms or Lists of things (different groups of issues, projects or
>taks, etc) and somehow there is a need to List in a single table (preferred)
>Items from different groups or Wikiforms. There is not a simple solution to
>this matter that I have read about yet.
>
>The escenario is the following (I also believe is the same situation for
>everybody in differet applications):
>
>- Let's say we have a master List of Stock Management (this could be a Book
>List, Project List, Issue List, etc.) 
>- Every part we define could have a list for their properties, like a list
>of vendors, datasheets, manafuturers, etc.
>- Let's Say now that we want to create another page or project (not
>necessarily with wikiforms). This Project has a BOM (bill of materials),
>this bill of material is a list of parts that have to be taken from the
>master list. So we need someway to use the wikilist to display let's say
>Item1, item3, item5, etc from the mater list. Or there must be a way to pick
>or include a single item from that master list into our wikilist in this
>project.
>
>I hope you can understand this scenario. I believe if we can find a way to
>implement a markup or logic or maybe some code in order to be able to
>implement that scenario then a lot of people will be able to finish their
>project the way they want to and also there will be a bunch of new possible
>aplications for wikiforms.
>
>Hope this helps, any comments are welcome either from you or from any other
>who may be interested in this matter,

Let me do some "thinking out loud" -- I think the problem you describe is
closely related to the "put all the issues in one group" problem discussed
earlier. If I have a Project group and a Part group, then I think you are
describing a Project-Part group, which represents the many-to-many
relationship between Projects and Parts. One project requires many parts and
one part can be used on many projects. The name of a page in the Project-Part
group is ProjectNumber-PartNumber and this provides links back to
Project.ProjectNumber and Part.PartNumber pages. Strictly speaking, the
Project number plus the Part number uniquely identifies the page; it may
or may not be the page's physical name.

The Project and Project-Issues problem discussed earlier is a special case of
this where the relationship is one to many: one project can have many issues,
but an issue is associated with one and only one project. If we can solve the
general case of Part, Project and Project-Part, we can solve the special
case of Project and Project-Issue.

I see 2 options for the Project-Part group:

a) the name of the page is made by concatenating the Project number and the
   Part number (assuming for simplicity that both are numbers; they need 
   not be). Thus If Project.00004 uses Part.00025, there is a page called
   Project-Part.00004-00025.

b) the name of the page is a meaningless sequential number and the page
   has attributes Project number and Part number. So Project-Part.12345
   might have attributes [[Project.00004]] and [[Part.00025]].

My first instinct (which may not be right) is to start with option b.
Let's take the Project-Issues scenario first. I am sitting on a page
for Project.00004 and wish to raise a new issue. I click a New Issue
link on that page and it takes me to an issue form with Project.00004
already filled in. I fill in the rest of the form and create a new
page called, for example Project-Issue.00246 -- it includes a link to
Project.00004 and I can generate a list from Project.00004 of all
the issues for that project.

The Project-Part scenario is an extension of this -- there are 2 links
per Project-Part page, one to the Project and one to the Part. If I
get to the new Project-Part form from the Project page, again the
Project number will be filled in. Ideally, we would want the Part
field to be a pick list generated from the Part group, but this
feature might be added later, once the concept is proved.

To get this to work, we also need a wikilist feature that matches
on an exact field value, which interestingly is a capability
requested this very day by another user for another purpose.

I think the main features we need to create a proof of concent are:
- a way to set a field based on the name of a page in another group
- a way to list items based on the name of a page in another group

Both of these would, I think, be easier than trying to add support
for a page name prefix. Note that using attributes scales: you can
define as many links to external groups as you need; if there is a
3-way intersection (Person-Fee-Project) for example, the page has 
an attribute for each link.

What do people think? In particular, is there a compelling reason
why a page *must* be called Project-Part.00004-00024 (or
Issues.Project00004-00002) rather than have these as attribute
values of the page itself? Unless there is a really compelling
reason, I'd rather not go there. It appears to me that it would
add a lot of coding complexity for little benefit.


-- 
JR
--
John Rankin

       \_      
        \)   
         \,\__/7
         /    /
        (   c'
         \  / 
     /,  /_/  
    |  & *   Wellington
    )  /    
   /  /,    
  /  (    
 |   /      
 \__/       
   V