From: <and...@f2...> - 2010-09-02 13:58:10
|
Hello Yaron. Okay, thanks for the info. I'll give it a go, but may have to hold off until the apostrophe fix is released. Also, can I still use SFI 0.2 with SF 2.0? I seem to remember seeing that the date picker no longer works with SFI 0.3 which is a bit of a show stopper for me. Thanks for your help. Andrew. >> Hi, Sorting of categories in 'values from category' works well for me in version 2.0, but then again I thought it worked fine in 1.9.1, so I can't say for sure that this will fix your problem. But I temporarily added 'values from category' to one of my test forms, and it works fine there - see the "Country" field here: http://discoursedb.org/wiki/Special:FormEdit/City/Madrid -Yaron |
From: <and...@f2...> - 2010-09-02 14:06:34
|
Hello. Thanks for your reply. I created the concept and it results in a page with the values sorted correctly. However, in the dropdown in the form the values are still not sorted unfortunately :( Just to make sure I'm doing something wrong here, my form contains: ! Faculty: | {{{field|Faculty|mandatory|values from category=Faculties}}} The concept is: {{#concept: [[Category:Faculties]] | sort= }} Thanks Andrew. >> I'm still in the dark ages with version 1.9. I had sorting issues with values from category, and for all I know that might be because that version didn't sort. But in terms of ensuring that it sorts however you want it to, you could always do values from concept and make a concept for your category, like Concept:Platform {{#concept: [[Category:Platform]] | sort= }} |
From: <and...@f2...> - 2010-09-02 14:11:01
|
Sorry, I'm being dense here aren't I. After creating the concept I then needed to do: ! Faculty: | {{{field|Faculty|mandatory|values from concept=Faculties}}} Doh! All working now. Nice sorted list for my users :) These concepts look interesting. I must get my head round them! Thanks Andrew. >> Hello. Thanks for your reply. I created the concept and it results in a page with the values sorted correctly. However, in the dropdown in the form the values are still not sorted unfortunately :( Just to make sure I'm doing something wrong here, my form contains: ! Faculty: | {{{field|Faculty|mandatory|values from category=Faculties}}} The concept is: {{#concept: [[Category:Faculties]] | sort= }} Thanks Andrew. |
From: <and...@f2...> - 2010-09-02 14:24:29
|
Sorry, one more question on this. Is there any particular reason why there is no "values from property"? I could see this being useful when you have a property that contains values that users have put in. Semantic Forms seems to have every other type of "values from" functionality covered, so it seems strange to be missing! Thanks Andrew. |
From: Yaron K. <ya...@gm...> - 2010-09-02 14:46:49
|
Hi, To answer your two questions: - everything is working fine in the latest version of Semantic Forms Inputs, 0.3.1. That's the version everyone should be using anyway, because the previous versions apparently had security leaks. - there's no 'values from property' parameter just because I never saw a compelling reason to add it in - restricting the allowed inputs for a property that's not defined to be restricted seemed odd to me. The one good reason for having it, that I saw, is so that the user can see all the existing values right from the beginning - but the new 'combobox' input in SF 2.0 takes care of that, in my opinion. In fact, the combo box might be a better alternative to using any of the other 'values from...' options, either - not that I'm planning to get rid of the existing ones. -Yaron On Thu, Sep 2, 2010 at 10:24 AM, <and...@f2...> wrote: > Sorry, one more question on this. > > Is there any particular reason why there is no "values from property"? I could > see this being useful when you have a property that contains values that users > have put in. Semantic Forms seems to have every other type of "values from" > functionality covered, so it seems strange to be missing! > > Thanks > Andrew. > > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: <and...@f2...> - 2010-09-02 15:45:50
|
Hello Yaron. The reason I see it as useful is that we have two levels of users - staff and students. So the idea is that staff members can add items to properties and then the students can then select those values, but not add new ones. I would think that this would be a fairly common need. If this is something that the new combo box functionality can achieve then that would be great. Perhaps it is time for me to play with version 2.0 :) Thanks Andrew. >> Hi, To answer your two questions: - everything is working fine in the latest version of Semantic Forms Inputs, 0.3.1. That's the version everyone should be using anyway, because the previous versions apparently had security leaks. - there's no 'values from property' parameter just because I never saw a compelling reason to add it in - restricting the allowed inputs for a property that's not defined to be restricted seemed odd to me. The one good reason for having it, that I saw, is so that the user can see all the existing values right from the beginning - but the new 'combobox' input in SF 2.0 takes care of that, in my opinion. In fact, the combo box might be a better alternative to using any of the other 'values from...' options, either - not that I'm planning to get rid of the existing ones. -Yaron |
From: trueskew <tru...@gm...> - 2010-09-02 16:03:51
|
I'm used to what you're describing with local applications (e.g. embedded/desktop GUI apps), where, from a separate thread, you can change attributes at runtime, point to a particular entry the case of a combo box, hide it, gray it out, make it read only, or make it editable. I don't think the nature of the controls in Semantic Forms should ever have that level functionality, that's a lot of overhead given the environment it runs in. I suppsoe in this case SF could be modified to include an |admin-only field for combo boxes that says it's not editable by normal users. Or is it not accessible by normal users? Let the overhead begin. For what it's worth, I've got the same scenario of admins being able to add options that other users can only select from. To do that cleanly in web world, I created a separate settings interface that's only accessible to admins. -----Original Message----- From: and...@f2... [mailto:and...@f2...] Sent: Thursday, September 02, 2010 8:46 AM To: sem...@li... Subject: Re: [Semediawiki-user] Semantic Forms - Values from category alphasort Hello Yaron. The reason I see it as useful is that we have two levels of users - staff and students. So the idea is that staff members can add items to properties and then the students can then select those values, but not add new ones. I would think that this would be a fairly common need. If this is something that the new combo box functionality can achieve then that would be great. Perhaps it is time for me to play with version 2.0 :) Thanks Andrew. >> Hi, To answer your two questions: - everything is working fine in the latest version of Semantic Forms Inputs, 0.3.1. That's the version everyone should be using anyway, because the previous versions apparently had security leaks. - there's no 'values from property' parameter just because I never saw a compelling reason to add it in - restricting the allowed inputs for a property that's not defined to be restricted seemed odd to me. The one good reason for having it, that I saw, is so that the user can see all the existing values right from the beginning - but the new 'combobox' input in SF 2.0 takes care of that, in my opinion. In fact, the combo box might be a better alternative to using any of the other 'values from...' options, either - not that I'm planning to get rid of the existing ones. -Yaron ---------------------------------------------------------------------------- -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Semediawiki-user mailing list Sem...@li... https://lists.sourceforge.net/lists/listinfo/semediawiki-user |
From: <and...@f2...> - 2010-09-02 16:28:54
|
Hello. I don't think I'm doing anything as complicated as what you are describing. I just have simple forms with selectable values. I just need it match a pretty basic real world need of ensuring a user picks a valid value. Like you, I have an admin page that allows staff members to put in values. In this form the field is set as a string input. Then in the student facing form the field is simply shown as a drop down to the students and they pick one of the values. At the moment I have to do this by effectively having the property values create a page of the same name in a category and then use values from category=. This is the only bit that is unnecessarily complicated. I'm having to use a category and dummy pages just to build a list that already exists in the property! If I could have values from property it would be simple and elegant. Okay, I could have the staff editing the property to add an extra * [[Allows value::blah]], but this has it's own problems and is not user friendly. Thanks Andrew. >> I'm used to what you're describing with local applications (e.g. embedded/desktop GUI apps), where, from a separate thread, you can change attributes at runtime, point to a particular entry the case of a combo box, hide it, gray it out, make it read only, or make it editable. I don't think the nature of the controls in Semantic Forms should ever have that level functionality, that's a lot of overhead given the environment it runs in. I suppsoe in this case SF could be modified to include an |admin-only field for combo boxes that says it's not editable by normal users. Or is it not accessible by normal users? Let the overhead begin. For what it's worth, I've got the same scenario of admins being able to add options that other users can only select from. To do that cleanly in web world, I created a separate settings interface that's only accessible to admins. |
From: trueskew <tru...@gm...> - 2010-09-07 02:46:16
|
I'd like to keep using the link method of creating an article using a form, as in [[Form:formname | Click Here]], since I've got specific information on the form page that helps the user create an appropriate name for their article. So the user enters the name and hits the "Create or edit" button and has a good time adding content. I'd like to prepend their selected name with a specific custom namespace. I know I can do this with the one-step method. But in the link situation I'm describing, is there a way to automatically prepend the namespace to their selected name, or does the user have to manually include the name space, like TheNameSpace:Article Title? Thanks. - skew |
From: Yaron K. <ya...@gm...> - 2010-09-13 07:31:29
|
Hi, You should be able to do that by adding the parameter "|query string=namespace=TheNameSpace" (or whatever it is) to the #forminput call. -Yaron On Mon, Sep 6, 2010 at 10:46 PM, trueskew <tru...@gm...> wrote: > I'd like to keep using the link method of creating an article using a form, > as in > > [[Form:formname | Click Here]], > > since I've got specific information on the form page that helps the user > create an appropriate name for their article. So the user enters the name > and hits the "Create or edit" button and has a good time adding content. > > I'd like to prepend their selected name with a specific custom namespace. I > know I can do this with the one-step method. But in the link situation I'm > describing, is there a way to automatically prepend the namespace to their > selected name, or does the user have to manually include the name space, > like TheNameSpace:Article Title? > > Thanks. > - skew > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: trueskew <tru...@gm...> - 2010-09-13 14:33:20
|
Thanks Yaron. -----Original Message----- From: Yaron Koren [mailto:ya...@gm...] Sent: Monday, September 13, 2010 12:31 AM To: tru...@gm... Cc: sem...@li... Subject: Re: [Semediawiki-user] Prepending a specific namespace to an article name Hi, You should be able to do that by adding the parameter "|query string=namespace=TheNameSpace" (or whatever it is) to the #forminput call. -Yaron On Mon, Sep 6, 2010 at 10:46 PM, trueskew <tru...@gm...> wrote: > I'd like to keep using the link method of creating an article using a > form, as in > > [[Form:formname | Click Here]], > |