Idea

The short answer is that there's not a great way to do this yet.

 

For this particular case, what I'd really like to do is have it look for +images, and the editor itself would take care of allowing multiple images (each to be stored in a separate card).

 

It is possible to write modules for this sort of thing, but the javascript support is what we really need here, and that's not really well supported in our pack system yet.

 

One workaround is to use a pointer, show the items in content view, and enter image names (even if they haven't been created yet) into the field.   this is fine for power users, but it's not very discoverable.

---

Woudn't there be a way like this? You would have a card which would be always displayed on your card like type:Image;config:persistent. This card could not be actually edited, it would serve as a dummy card. If the user will click save then this card gets transformed into a regular image card and becomes really a part of the card where this persistent card was shown.

 

Is that a possible way how do it in the future? I don't really know yet (the code base is quite LARGE) but I get this feeling this could be a logic which could fit Wagn.

 

Patrik

  --Tukanos.....2013-02-16 20:23:47 +0000

---

how is that connected to the dynamism? I thought what was wanted was a way to add unlimited numbers of cards, no?

  --Ethan McCutchen.....2013-02-18 01:29:28 +0000

---

Yes, that is the goal.

 

What I described is the mechanism of having card ready always ready for input (never ending in a sense) - like image card. I will try to explain it with example:

 

The user wants to add 2 pictures. If you prepare template with this "generic" type it would look like

 

Step 1) ....persistent card....

 

Step 2) after clicking on the button save you would have:

     .....image 1 by user...

      ....persistent card....

 

Step 3) User enters another image using the persistent card

      ...image 1 by user...

     ...image 2 by user...

    ....persistent card...

 

and so on.

 

The card would be there always and so enabling the user to add new instances of predifined type.  I hope I explained this better than the last time.

 

Patrik

 

P.S. Now, the only way to do it is to have 3 static fields.  The user can use two cards and one leave empty.  What will happen if the user needs 5 cards? ( two will be missing then)

 

  --Tukanos.....2013-02-18 14:04:09 +0000

---

interesting! ok, I get it now. I'd want to play with the syntax a bit (we have to figure out how to support a card with no name. eg is {{|new; type:Image}} really all we need for that part (and a search for the other part)?

 

Nice thinking, Tukanos

  --Ethan McCutchen.....2013-02-18 21:37:13 +0000

---

Excellent inquiry. Not seeing how a Search could find the cards that had already been added. So I'm still thinking a Pointer, but with a new view ("addable" ?) that shows existing cards in the Pointer (if any) the same as currently, and below them a grayed out "add Image" (or whatever cardtype). When you add a card it's added to the Pointer, displayed, and another grayed-out "add Image" appears below it.

  --John Abbe.....2013-03-13 04:59:42 +0000

---

this may be part of the solution for quick upload interface for multiple files or images

  --John Abbe.....2013-03-13 09:40:39 +0000

---

I'm really glad that you like the idea :).

 

Last few weeks I was trying to setup wagn, but still some issues. When I have better understanding of the problems, I will write some support tickets.

  --Tukanos.....2013-03-25 17:56:23 +0000

---

John, I think you're right about pointers. the search idea was based on the notion that there were many cases (eg list of photos) where users wouldn't want to be bothered with naming, so we'd just an autoname that could be used in the search. but the pointer option is more general, so I'd say we go that route.

  --Ethan McCutchen.....2013-03-25 18:07:26 +0000

---

WIth images or files, the Pointer could be included with item:content and no one would even see the autonames.

  --John Abbe.....2013-03-26 06:18:08 +0000

---

@Ethan, maybe the possibility would be to take over the file name and use it as card name.

@John, I think you are right about the Pointers, probably the best solution.

  --Tukanos.....2013-03-26 08:36:21 +0000

---

Hi there

could you already solve this issue?

I do have the same problem: need to setup a kind of "history card" where I need to add n "posts" (when, who, what) to have a protocol of what I did when working on this topic (recent post on the top of the list). I played around with pointers but couldn't find any practical solution.

 

Andreas

---

Pointers work fairly well for this. I have a type http://gerry.wagn.org/Book where the chapters are in a pointer card and I display them with the titled view. Then I just put the Chapter names in the pointer card and populate them as I write them.

 

Another idea is to use the autoname feature. I think I may have created an Idea card for this. Autoname is from before we had sets in wagn, but I think there are logical extensions of this idea that would be useful here. We can use a wildcard to match names in card searches, no? Then a search card could match an autonamed pattern. I remember playing with this a few months back.

---

What about implement autoname by type and implement autoname by right? I'm not sure these ideas a quite right yet, but it seems that some implementation has been attempted. Not sure if any of this works yet.

---

Right, I think the answer is that are several workarounds, but that Wagn should handle this pattern more elegantly.

 

The two main workarounds use Search and Pointers. The pointer workaround is simple enough. You typically just edit the pointer, add an item, save, then click on the item to add it in place. But this means you have to think of a name for each item, which can be really annoying (as in Andreas' example. The search workaround solves this by using autonames and setting default content with links. So to use Andreas' example, you might have Topic cards with several Posts. The Topic card would have a +post card that was a search for Posts with a +topic pointer that pointed to that topic. You set posts to autoname and add links on each topic card to add a new post for that topic, using the link to prepopulate the +topic pointer. That's a mouthful.

 

re the ideas you mention: implement autoname by type is closed; that's how autoname rules already work. the other ticket seems a bit confused, but perhaps we should merge it with this one, because we're getting at the same thing.

 

To me the main constraints are these:

 

1. we shouldn't have to think much about names.

2. we should be able to add the new cards in place

3. we should be able to query for these cards easily

4. we shouldn't have to go through anywhere near as much effort as the search workaround described above