Granted Wagn's file-handling could be better, but it's not quite as bad as you describe...

• You can default cards in a Pointer to be a certain type by adding in this case "Attachments"*right+*options" and putting in the WQL there:
  {"type": "File"}
• I'm pretty sure there's a way to autoname the cards so that people dont have to name them before uploading, but I lack the time to re-figure that part out myself at the moment (gotta go mow the lawn), maybe someone else can chime in or you could explore it yourself and see how far you get - see autonaming. It might require a different card structure, which may also help with your desire for the files to be auto-deleted when the Client is deleted.

--John Abbe

---

Hrm, looked at it a little more just now and I'm not seeing an elegant way forward. I thought of using File+*type+autoname with "{{_user|name}}+file0001" but that does not work.

 

Anyone else?

 

People with an account on test can see what I tried:

http://test.dwagn.org/File+*type+*autoname

http://test.dwagn.org/new/File (fails with: Can't save "{{_user|name}}+file0001".)

 

  --John Abbe.....2012-11-04 23:46:56 +0000

---

That's probably a bug, should be a bug report for it then.

 

But the basic idea is right. I think what is confusing is that with Wagn, you don't attach a File or Image to a card, it is a card. That gives a lot of power, but what it means is that to make an attachement, you will need to use the Wagn mechanism of a plus card, or alternatively a pointer card (probably still a plus card, but then you can have a list of images (cards) attached).

 

So, John's first point is that you make it so your attachement field (in John's rule, that is any card matching the pattern <some card>+Attachements). The autonaming thing is also possible, but a bit more tricky. John has either exposed a bug, or it needs a little tweaking.

  --Gerry Gleason.....2012-11-05 14:54:24 +0000

---

As far as deleting is concerned, when you delete a card, it checks first to see if it has referencers, which includes plus cards. It gives you a dialog where you can choose what you want to do (don't remove it, break the links, or delete references). Actually, I'm not sure it gives the last option, but I think it does or it should in some form). We are also working on an event system that could do arbitrary actions on the event of updates, deletes, etc. That will give more wagneering options on how this can be handled, and the out of the box defaults will be improved with this as well.

  --Gerry Gleason.....2012-11-05 15:09:12 +0000

---

Gerry, I forgot to escape the markup in my comment - fixed it now to show the actual error text. Not so much a bug as an un-implemented feature :-), anyway here's an Idea ticket for it: Interpret markup in names from plus-*autoname

  --John Abbe.....2012-11-05 16:16:28 +0000

---

A less-than-elegant way to handle this would be to not worry about having the File cards plussed to the Client card, and before deleting a Client delete their File cards by hand. You could easily get a list of them by making a Search card "client files+*right+*content" with this WQL:

{"found_by": "_self+*editing",

"type": "File",

"view": "open"

}

Then just go to "Client+client files" and you'll see a list of file cards they've edited and can easily go through and delete them.

  --John Abbe.....2012-11-05 17:06:32 +0000

---

In Wagn, Files are their own cards, and are much more flexible beasts than in most wikis. A given file can be connected to countless other cards. If you want to relate them to a client, then my first question would be "what is the relationship?"

 

If it's files edited by a client, then something like John's WQL would work (though the more natural wql would be to substitute the first like for "edited_by":"_self". For files created by a client, you could do similar WQL with "created_by":"_self".

 

You could also create a cardtype that is something like "assigned files" that have a +client value (which could be prepopulated in a link). And then you could replace the pointer idea above with a search for all files assigned to a given client. This is handy, because you could save a lot of grief in cases where a given file is assigned to many clients.

 

I agree that easy interface for attaching a list of autonamed files would be handy. We've discussed that, and I'm hoping we'll have something like that shortly after 2.0. I do know of a few other use cases. But I'm still of the mind that Wagn's approach has WAAAAY more long term potential than standard wiki attachments.

  --Ethan McCutchen.....2012-11-05 18:57:45 +0000

 

---

There is no question that Wagn's approach is wonderfully flexible. Despite its flexibility, however, there does not seem to be a way to address this use-case with the current feature set of Wagn.

 

The use-case seems to state:

a) The developer wants to be able to embed a list into a card, to which their user can arbitrarily add items (other cards), of a certain specific type.

b) when the 'parent' card is deleted, all sub-cards from the embedded list be automatically deleted as well.

 

It is currently possible for the developer to add a Pointer to a card, and specify the type of cards that will be added to the list, as mentioned above. This seems to solve requirement 'a'. However, in order to solve 'b', we need to be able to establish a true hierarchical relationship between the cards, and this can only be done with card names. Unless the user is 'helped' to autoname the card - 'linking' it to its parent - as mentioned by John above, requirement 'b' will not be fulfilled.

 

It seems to me, that this goes way beyond merely attaching files to a card. This design pattern is useful in a *very* wide variety of situations:

 

* adding 'Contact Logs' to a 'Client' (deleting Client must delete all Contact Logs)

* adding 'Charges' to an 'Invoice' (deleting Invoice must delete all Charges)

* adding 'Comments' to a 'Topic' (deleting Topic must delete all Comments)

* adding 'Contact Numbers' to a 'Supplier' (deleting Supplier must delete all Contact Numbers)

 

In all these situations, the embedded list will be of an arbitrary length, so it is not reasonable to add a pre-defined number of possible items in the parent card. Also, deleting the parent card *must* delete all its listed items, and it is not reasonable to expect the user to delete each entry manually, before deleting the parent.

 

I would be *very* interested in finding out from the more experienced developers here, if there is already a way to do this in Wagn.

  --Knud Potente.....2012-11-12 22:28:09 +0000

---

"...already a way to do this in Wagn?"

 

Short answer: no.

 

To confirm what's implied above, currently destroying triggers only one other class of cards to be destroyed: name dependents. A

"name dependent" in this definition is any card of whose name the current card's name is a part. So destroying either A or B destroys A+B. (notice that this is a little different from most trees, like file directories, in which /B has nothing to do with /A/B.

 

You define the problem very well and clearly, and I think we can come up with a robust solution by 2.0. To a Wagneer it would probably look something like a special edit view for pointers and a modification of our autonaming. To a normal user it would mean that when you click "add another", you just get the interface to create a new card.

 

If you were interested in considering paying for a modification like this, I'd be happy to put together a bid. First guess is that it would be in the $500-$1000 range.

  --Ethan McCutchen.....2012-11-12 23:15:16 +0000

---

I recall seeing a website once where people could announce software they'd like built, and they and others could make pledges until a developer looked at the total pledged and agreed to do it for that amount. This was before the recent "crowdsourcing" term/craze but I can't remember the name and a quick Google search failed to turn it up. If we can't find a tool like this, we could try to Wagneer such a thing...

  --John Abbe.....2012-11-12 23:48:18 +0000

---

see Dynamic wagn cards

  --John Abbe.....2013-03-13 09:57:00 +0000

---

We've talked about exactly that in the context of another project: Source Tree Commons. If Art will let me have the domain names, I would like to build out that project under the original name, if not, I can find another one.

 

What we really want is a Community of Practice with currencies infrastructure. All of that is my top priority after 2.0.

  --Gerry Gleason.....2013-03-13 10:59:40 +0000