How to fill the The 'select' field type ?

««

»»

Steven Heynderickx wrote on 05 Jan 2010 09:14

If this is the structure of a select field type

[[form]]
fields:
  your-mood:
    label: Your mood
    type: select
    values:
      1: manic
      2: happy
      3: calm
      4: down
      5: depressed
[[/form]]

It would be useful to pull these values (both the internal 'key' and the external 'label' from wiki pages in a category). In a minimum case, we'd use all pages in a category. In a more sophisticated case (but this is probably overkill right now) we'd want selection and ordering mechanisms similar to that used in ListPages.

Start a new sub-thread

Comments: 15

pieterh 05 Jan 2010 11:47

No, this would not be possible. There is no way we're going to enable modules inside form definitions like that.

But that's what you're asking for, is it? What you are asking is "can we build select fields from wiki pages, rather than hard coded values" but then instead of telling me that, you're jumping to a solution and forcing me to reverse engineer your solution back into a problem. Since you are not a product designer with knowledge of the internals of Wikidot, your solution is by definition wrong.

Please ask the right questions.

Define the problem, accurately. What is the problem with writing select values by hand? It is fast, simple, obvious. Creating pages is much harder work.

But we can in some cases consider a category as a database table, and pages as rows. Especially if we use forms. So for example I could create a category of people, and then assign an issue to a person.

Period.

Then allow the community to expand on the problem statement, and allow the designers (me, principally) to turn that problem statement into design sketches.

Cheers! :-)

---

Portfolio

I try to ask the correct question

Steven Heynderickx 05 Jan 2010 12:28

FIRST:
the parent of this thread is:
Implementation and possibilities of Data Forms

So in this thread I ask for a possible functionality since it is not described in the mother design.

I did not wish to MAKE a design, I wanted to ASK something regarding the design. Now since you changed it… there is no questionmark any more… is became a design. If I can't ask questions about a design here… then this thread should not have been moved here.

SECOND :
Do you think I now have more insight to this problem? Did you help? No I still have the same question, I am waiting for solutions, I am trying to be as creative as possible with the tool I have, and you tell me "your solution is by definition wrong". Where I did not even give a solution but I asked a question. and I did it in the best way I could: I give you an example of what I wished for… Imagine that I would have asked
"will the lists in select fields always be hard coded or is there a way to automize this?"

Is that so much different from what I wrote? If I did this… there would again be an interpretation and there would probably follow an explination that is of no use to me or the question to specify what I realy mean by "automize"… You know the ins and outs of wikidot… reverse engineering is peanuts for you… And as you can see you had it right from the first time.

THIRD
I find it hard to believe to hear from you that you can in some cases look at a category as it were a table in a database… A page as a row and a contentblock as a cel. We had a very difficult conversation were I was trying to explain this… Do you remember… and now you say it yourself…

I will put a smiley here but I am not smiling after reading what's up there, saying something like "your solution is by definition wrong" sound to me like "you're stupid" I find that offensive. In dutch there is a saying "there are no stupid questions, only stupid answers". I was asking for info nothing more, I was not making a design.
:-)

---

A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.

Last edited on 07 Jan 2010 08:14 by Steven Heynderickx Show more

Re: I try to ask the correct question

leiger 08 Jan 2010 12:41

I also thought pieter's reply was a bit … harsh. But I'll stop there, it was a misunderstanding.

Steven… you are asking for a certain feature. What pieter would like to know, if I'm not mistaken, is exactly what you plan to use this feature for? Can you explain specifically what you plan to do if this feature is added?

---

~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)

Re: I try to ask the correct question

pieterh 08 Jan 2010 14:33

I also thought pieter's reply was a bit … harsh. But I'll stop there, it was a misunderstanding.

Well, sorry about that… yes, I was harsh. I'm sure Steven will kick me next time we share a beer.

People who ask me long, complex questions that make loads of assumptions which I need to deconstruct in order to get to the real point will always get a fairly brutal response from me. Perhaps there are not stupid questions but there are definitely stupid patterns, and one of these is to propose answers and ask, "is this the right answer", without explaining the question.

I explained Steven's email to Piotr who answered, in 5 seconds, "pagepath!"

So again, here is a smart pattern:

• explain a high level need (not a proposed solution!)
• allow an expert to propose a solution
• if it is unclear, ask for more detail
• test solution against need until it is acceptable
• implement solution etc.

Question: "In my form I want to choose the mood from a list that can be extended by any user…"

Answer: "You would define moods as pages in the mood: category and use a pagepath field to hold the defined mood".

There. Two lines.

Now let me deconstruct some of the assumptions in the design sketch:

• That no-one has already thought about this (so that we need to invent something new)
• That it's necessarily a select field type (this is hardcoded in the title of this page)
• That it makes sense to mix modules in form definitions (ignoring that there is an architecture we have to work within)
• That there is a use case somewhere for selection and ordering on such lists (typical but flawed assumption that any functionality that appears interesting must by definition have use cases)

Etc.

I'm not asking for much, just that before people provide detailed technical proposals that need deconstruction, and reverse engineering before being binned and replaced with an accurate design, they just step back and provide a high level use case.

---

Portfolio

Following the smart pattern

Steven Heynderickx 08 Jan 2010 16:44

• explain a high level need (not a proposed solution!)
• allow an expert to propose a solution.

Solution : in 5 seconds, "pagepath!"

• if it is unclear, ask for more detail

This is unclear, specialy in the context of expanding a select-field by a user.
More datail please…

• test solution against need until it is acceptable

When can we test it?

• implement solution etc.

---

A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.

Last edited on 08 Jan 2010 16:45 by Steven Heynderickx Show more

Re: Following the smart pattern

pieterh 08 Jan 2010 17:35

Thank you for playing ball! :-)

Let's step back and look at requirements.

• The ability to structure your values in some kind of hierarchy. Reason: more than 50-100 values creates unusable select lists. E.g. authors can be grouped by language. Users can then navigate much more easily to the right value.
• The ability to add new missing values immediately. Example: user wants an author but the author is missing. Ideal pattern is to add new author immediately, and then select it.
• The ability to see detail on a value. An author is not just a value but a page with its own detail.
• The ability to nest such references. E.g. book -> author -> language

These are the high level functional requirements that the pagepath field type handles. You can see now that the 'mood' example is a simplified use case of this. And you can see, I hope, why I asked you to step back and look at real needs, rather than solutions.

Now for testing this: we need to implement the pagepath field type, and then you can test it. I will review the design for that part of the form data spec and make sure it's clear.

---

Portfolio

Re: Following the smart pattern

leiger 09 Jan 2010 00:08

• The ability to add new missing values immediately. Example: user wants an author but the author is missing. Ideal pattern is to add new author immediately, and then select it.

The ability to prevent this from happening would also need to be implemented. If the user doesn't have permissions to create new pages in that category, they shouldn't be provided with the option to do so.

This could either be a manual setting using wikidot code that applies to all viewers, or it could be automatically based on whether the current user has the correct permissions.

---

~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)

no title in email

Steven Heynderickx 10 Jan 2010 12:43

ListUsers

I think this can be managed with the ListUsers Module…

---

A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.

Last edited on 10 Jan 2010 12:44 by Steven Heynderickx Show more

no title in email

Steven Heynderickx 08 Jan 2010 18:03

if I may comment on number of values.

indeed you are right if you think of them as things to open en scroll untill you encounter your selection but in combination with some javascripting and typing in the selection… you can easely use lists from over 1000 items. The limiting issue there is the amount of data that needs to be transferred in the html.

please have a look at a mockup
http://kempies-forum.wdfiles.com/local--files/main:start/postcode.html

---

A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.

Re: no title in email

pieterh 08 Jan 2010 18:12

Sure, there are workarounds for this but that is a technical detail which could also apply to pagepaths.

The more important point is that reference data (such as postcodes) are naturally structured, and more significantly, they tend to be infinite sets that need maintenance. Postcodes are not typical. Authors are much more typical.

A key reason for using wikis is that this mass of data is economically created and maintained by collective effort. This is absolutely central. Entering and fixing reference data are real problems to solve, as well as navigating through the data set. This is what you will want to test, when you play with pagepath fields.

---

Portfolio

Re: no title in email

leiger 09 Jan 2010 00:09

please have a look at a mockup
http://kempies-forum.wdfiles.com/local--files/main:start/postcode.html

Not authorized. This is a private site with access restricted to its members.

---

~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)

no title in email

Steven Heynderickx 10 Jan 2010 12:41

replaced it

http://testingzone.wikidot.com/local--files/start/postcode.html

---

A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.

no title in email

Steven Heynderickx 08 Jan 2010 18:31

Sure!

But I also made this javascript thing for a dictiornary russian - dutch list of about 3000 words. I do not understand what you mean with typical an not typical.

I am just pointing out that long lists in pulldowns can also be "made easy" so I think the technology that I showed in the mockup could also work for the pagepath…

BTW i cam across the testing page of piotr on the dev-server I think
I am wondering though… I find it not so easy to understand how it works. This with a little of investigating on the www.wikidot.com - site on the "what's hot" page, makes me think that, if you look at the sites in the top 5 adjustments this month… I think 4/5 don't even use live templates to generate more than 1000 page per month… We still have a long way to go so that non-guru's can benifit from the modules (not even speaking of a strange animal like a pagepath)

---

A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.

Re: no title in email

pieterh 08 Jan 2010 20:45

Ack!

---

Portfolio

no title in email

Steven Heynderickx 11 Jan 2010 16:47

As some proof of what I just wrote:

Stacey Dyer 7 Jan 2010, 16:38 +0100

Hi there, sorry to jump on this thread, it is a related enquiry of 
sorts! I too would love to customise the default search to 
include uploaded file based searches rather than simply page 
content of my wiki. Is this at all possible, my wiki relies heavily 
on people being able to search for uploaded images.

Thanks

leiger 11 Jan 2010, 02:18 +0100

If you can set up your wiki so that there is one image per 
page, that will work. People can use the search boxes to find 
pages, which would hold just one image. Your live template 
would look something like this:

> %%content%%
> [[image :first]]
> ====
> [!-- your description here, save and upload your image. --]

Stacey Dyer 11 Jan 2010, 16:04 +0100

Bit tricky to be honest leiger; my wiki allows access to multiple 
collection specific galleries i.e. in one collection alone we have 
over 800 images thus 800 individual pages for just that one 
collection would prob. not be the best option!

Thanks anyway though. :)

at http://community.wikidot.com/forum/t-175540#post-672693

---

A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.