Did you take a look at the "Default input types for data types"
section in semantic form homepage? You may see a "dropdown" input type
for data type "Enumeration". That means if you set an attribute as
Enumeration type with a list of "Allows value" defined, you will see a
dropdown list for corresponding attribute in your semantic form.
Guoqian
On Jul 21, 1:48 am, Eep² <e...@tnlc.com> wrote:
> I'm trying to use MediaWiki to create a database for my 3D Game
> Comparison (http://tnlc.com/eep/compare/), and I'm trying to use
> Semantic Forms to create forms (ideally, the one athttp://tnlc.com/eep/compare/gameform.html) for computer/video game
What I want is for the "allows value" article to automatically pull category groups (games, companies, engines, player characters,
etc) without the "allows" value" article having to be manually updated everytime a new category is created (of which there will be
hundreds, eventually, for every possible field in my current gameform at the aformentioned URL.
Plus, for each dropdown, checkbox, or radio button (is that input type even possible?), I want a blank text field for custom/new
terms not already present in the list (and some misspelling/error-checking would be nice to offer suggestions of possible existing
terms) which, once approved, will become part of the form for future selection.
Then I want to pull in all of these fields from games which can be configured to only show certain games/features (fields) with the
game name in columns and the features/fields in rows.
Are these things possible with Semantic Forms and, if so, how would I implement them? Thanks.
From: "guoqian" <gqj...@hotmail.com>
Sent: Saturday, July 21, 2007 2:50 PM
Did you take a look at the "Default input types for data types"
section in semantic form homepage? You may see a "dropdown" input type
for data type "Enumeration". That means if you set an attribute as
Enumeration type with a list of "Allows value" defined, you will see a
dropdown list for corresponding attribute in your semantic form.
On Jul 21, 1:48 am, Eep² <e...@tnlc.com> wrote:
> I'm trying to use MediaWiki to create a database for my 3D Game
> Comparison (http://tnlc.com/eep/compare/), and I'm trying to use
> Semantic Forms to create forms (ideally, the one at http://tnlc.com/eep/compare/gameform.html ) for computer/video game
- it sounds like what you're looking for is an autocomplete - it both
shows available options, lets you enter new values, and helps with
spell-checking and the like. I don't quite understand what the set of
values you want for this field (or fields) is, but you can set
autocompletes to hold either the values of a relation or a category -
check the documentation.
By the way, what you actually might be looking for is a combo box, a
combination autocomplete and dropdown. There was discussion of this on
the mailing list last week. Unfortunately, Semantic Forms doesn't
support combo boxes, though the plan is that they will eventually.
- radioboxes aren't supported in Semantic Forms, though they could be
easily; there hasn't been any request for them yet.
- forms can't be created in wiki markup, only HTML; you can always
look at the source code for the pages, then copy it over as
appropriate for the form. I think it would be possible to have forms
be creatable in wiki markup, though, as before, no one has requested
that feature yet.
One final thought is that, from what I understand of your description,
you might be trying to compress too many things into one form. If you
want users to be able to add games, companies, engines, etc., it makes
sense to have a different form for each of these.
-Yaron
But, according to the docs (http://discoursedb.org/SemanticForms/ anyway), "autocomplete" is only for text fields, but I want a
select/dropdown/pulldown list filled with the entries in a category (or categories).
> By the way, what you actually might be looking for is a combo box, a
> combination autocomplete and dropdown. There was discussion of this on
> the mailing list last week. Unfortunately, Semantic Forms doesn't
> support combo boxes, though the plan is that they will eventually.
A combo box would be nice.
> - radioboxes aren't supported in Semantic Forms, though they could be
> easily; there hasn't been any request for them yet.
I'd like to put in a request for this. :)
> - forms can't be created in wiki markup, only HTML; you can always
> look at the source code for the pages, then copy it over as
> appropriate for the form. I think it would be possible to have forms
> be creatable in wiki markup, though, as before, no one has requested
> that feature yet.
Ditto.
> One final thought is that, from what I understand of your description,
> you might be trying to compress too many things into one form. If you
> want users to be able to add games, companies, engines, etc., it makes
> sense to have a different form for each of these.
Yes, as http://tnlc.com/eep/compare/gameform.html : "The final form will have multiple pages to make adding all this information
easier and less overwhelming--at least initially. ;)"
And a general comment: for claiming to not requiring programming skills to use, Semantic Forms actually does require programming. It
really needs a more user-friendly design akin to, say, content mananagement system configurations.
> >
> > - it sounds like what you're looking for is an autocomplete - it both
> > shows available options, lets you enter new values, and helps with
> > spell-checking and the like. I don't quite understand what the set of
> > values you want for this field (or fields) is, but you can set
> > autocompletes to hold either the values of a relation or a category -
> > check the documentation.
>
> But, according to the docs (http://discoursedb.org/SemanticForms/ anyway), "autocomplete" is only for text fields, but I want a
> select/dropdown/pulldown list filled with the entries in a category (or categories).
Which would then be used to populate a text field, I'd assume.
>
> > By the way, what you actually might be looking for is a combo box, a
> > combination autocomplete and dropdown. There was discussion of this on
> > the mailing list last week. Unfortunately, Semantic Forms doesn't
> > support combo boxes, though the plan is that they will eventually.
>
> A combo box would be nice.
>
> > - radioboxes aren't supported in Semantic Forms, though they could be
> > easily; there hasn't been any request for them yet.
>
> I'd like to put in a request for this. :)
>
> > - forms can't be created in wiki markup, only HTML; you can always
> > look at the source code for the pages, then copy it over as
> > appropriate for the form. I think it would be possible to have forms
> > be creatable in wiki markup, though, as before, no one has requested
> > that feature yet.
>
> Ditto.
Combo boxes would indeed be nice; right now it's pending some
improvements from the main Javascript library producers (see the Ajax
thread from before).
I'll look into adding support for the other two.
>
> > One final thought is that, from what I understand of your description,
> > you might be trying to compress too many things into one form. If you
> > want users to be able to add games, companies, engines, etc., it makes
> > sense to have a different form for each of these.
>
> Yes, as http://tnlc.com/eep/compare/gameform.html : "The final form will have multiple pages to make adding all this information
> easier and less overwhelming--at least initially. ;)"
This page always shows up as blank when I go there, by the way.
>
> And a general comment: for claiming to not requiring programming skills to use, Semantic Forms actually does require programming. It
> really needs a more user-friendly design akin to, say, content mananagement system configurations.
>
Well, it depends on whether you consider writing in a markup language
to be programming; I don't, though some people do. That's a bit of a
semantic issue (no pun intended).
As for user-friendliness, I'm always looking for ways to make the
whole system more user-friendly; any suggestions would be welcome.
-Yaron
>> > - it sounds like what you're looking for is an autocomplete - it both
>> > shows available options, lets you enter new values, and helps with
>> > spell-checking and the like. I don't quite understand what the set of
>> > values you want for this field (or fields) is, but you can set
>> > autocompletes to hold either the values of a relation or a category -
>> > check the documentation.
>>
>> But, according to the docs (http://discoursedb.org/SemanticForms/ anyway), "autocomplete" is only for text fields, but I want a
>> select/dropdown/pulldown list filled with the entries in a category (or categories).
>
> Which would then be used to populate a text field, I'd assume.
Yes, but if "autocomplete" is for text fields, how would I use it on a select list?
>> > One final thought is that, from what I understand of your description,
>> > you might be trying to compress too many things into one form. If you
>> > want users to be able to add games, companies, engines, etc., it makes
>> > sense to have a different form for each of these.
>>
>> Yes, as http://tnlc.com/eep/compare/gameform.html : "The final form will have multiple pages to make adding all this information
>> easier and less overwhelming--at least initially. ;)"
>
> This page always shows up as blank when I go there, by the way.
Should be fixed now; sorry.
>> And a general comment: for claiming to not requiring programming skills to use, Semantic Forms actually does require programming.
>> It
>> really needs a more user-friendly design akin to, say, content mananagement system configurations.
>
> Well, it depends on whether you consider writing in a markup language
> to be programming; I don't, though some people do. That's a bit of a
> semantic issue (no pun intended).
>
> As for user-friendliness, I'm always looking for ways to make the
> whole system more user-friendly; any suggestions would be welcome.
Well, not requiring so much scripting (markup language) would be a start. MediaWiki is fairly bad at adminstration compared to other
CMSes like Drupal, Joomla, XOOPS, etc. For example, you have a form to create a form so why not a form (WYSIWYG) to edit the form
too? Perhaps as an add-on to an existing WYSIWYG extension ( http://www.mediawiki.org/wiki/WYSIWYG_editor ) but something more basic
would be sufficient--perhaps even designed with Semantic Forms itself. ;)
Well, you don't really want a select list/dropdown, do you? After all,
you want users to be able to enter their own value, aside from all the
existing values. The ideal solution would be a combo box; until that's
available, the best solution, I think, is an autocomplete.
>
> >
> > As for user-friendliness, I'm always looking for ways to make the
> > whole system more user-friendly; any suggestions would be welcome.
>
> Well, not requiring so much scripting (markup language) would be a start. MediaWiki is fairly bad at adminstration compared to other
> CMSes like Drupal, Joomla, XOOPS, etc. For example, you have a form to create a form so why not a form (WYSIWYG) to edit the form
> too? Perhaps as an add-on to an existing WYSIWYG extension ( http://www.mediawiki.org/wiki/WYSIWYG_editor ) but something more basic
> would be sufficient--perhaps even designed with Semantic Forms itself. ;)
Well, it's much easier to implement this kind of administration and
form-creation for regular CMS's because they're not as flexible: they
don't allow all users to collaborate on the structuring of data, which
means you don't need to bother with all this text-based representation
of forms, or with specifying the type of a field on a separate page
from the main form, etc.
A WYSIWYG form editor would be an interesting feature, though it would
be a lot of work to implement. You can always use the HTML editor of
your choice to edit the form, in any case, then substitute the markup
as appropriate.
Using Semantic Forms to edit form-creating forms would require forms
to be defined using semantic markup; I had this idea early on, but it
would require support for n-ary relations, which doesn't exist at the
moment (and it might not even be worth it after then).
-Yaron
>> >> But, according to the docs (http://discoursedb.org/SemanticForms/ anyway), "autocomplete" is only for text fields, but I want
>> >> a
>> >> select/dropdown/pulldown list filled with the entries in a category (or categories).
>> >
>> > Which would then be used to populate a text field, I'd assume.
>>
>> Yes, but if "autocomplete" is for text fields, how would I use it on a select list?
>
> Well, you don't really want a select list/dropdown, do you? After all,
> you want users to be able to enter their own value, aside from all the
> existing values. The ideal solution would be a combo box; until that's
> available, the best solution, I think, is an autocomplete.
Actually, yes, I do. See, that's the user-friendliness thing again. User-friendly is a select list (or combo box); having to type in
values without knowing what to enter, is a bitch, autocompletion or not--ever been frustrated with your web browser's auto-complete
URL field? I have! I want the select list for existing articles/categories and a text-entry field for "other"/miscellaneous entries
that don't exist in the "database" yet (but will be once approved.
>> > As for user-friendliness, I'm always looking for ways to make the
>> > whole system more user-friendly; any suggestions would be welcome.
>>
>> Well, not requiring so much scripting (markup language) would be a start. MediaWiki is fairly bad at adminstration compared to
>> other
>> CMSes like Drupal, Joomla, XOOPS, etc. For example, you have a form to create a form so why not a form (WYSIWYG) to edit the form
>> too? Perhaps as an add-on to an existing WYSIWYG extension ( http://www.mediawiki.org/wiki/WYSIWYG_editor ) but something more
>> basic
>> would be sufficient--perhaps even designed with Semantic Forms itself. ;)
>
> Well, it's much easier to implement this kind of administration and
> form-creation for regular CMS's because they're not as flexible: they
> don't allow all users to collaborate on the structuring of data, which
> means you don't need to bother with all this text-based representation
> of forms, or with specifying the type of a field on a separate page
> from the main form, etc.
Actually, you should take a look at Drupal (http://drupal.org/) because it has such GUI form building (which is nothing new if
you're familiar with Visual BASIC) modules (CCK+Views) which, unfortunately, aren't quite user-friendly enough for me. I'm trying to
use Drupal to create this "database" as well but I keep hitting roadblocks. I know what I want to do but I don't have enough coding
experience (which I don't enjoy doing) to implement it.
Anyway, collaborative data structuring is entirely possible with a GUI; it's just a matter of pulling in all the text-stored into
various GUI controls such as my idea for Second Life's particle editor at http://tnlc.com/eep/sl/#lsl . In Second Life (a
collaborative virtual world 3D environment), editing one of its scripts is near-real-time, in that after you (re)compile it, the
effects are immediately visible. While this reaction time isn't necessarily necessary in MediaWiki, it's a "proof of concept". The
GUI editor would just make editing the underlying script (or a semantic form) easier, more seamless, and, thus, more user-friendly.
> A WYSIWYG form editor would be an interesting feature, though it would
> be a lot of work to implement. You can always use the HTML editor of
> your choice to edit the form, in any case, then substitute the markup
> as appropriate.
Note that the WYSIWYG editor would be for semantic forms, not HTML (even though semantic forms contain HTML, presently, if they
contain wiki markup, that would be another way to "express" the semantic form).
> Using Semantic Forms to edit form-creating forms would require forms
> to be defined using semantic markup; I had this idea early on, but it
> would require support for n-ary relations, which doesn't exist at the
> moment (and it might not even be worth it after then).
Well, that's what this is all about, really: expressing relationships. How the "form" is expressed through a textual interface
(currently) or a GUI (hopefully soon)--and, eventually, a neural interface--depends on its "relational expression" (or "expressed
relationship") between the end-user, the interface, and the end-result (the "form", other relationships that continue the process,
etc).
Anyway, I'm just looking for a way to "dumb-down" the data entry so it doesn't require scripting/programming/whatever to do it and
is "easy" as "doing without thinking" (unconsciously). I like the idea of a semantic web but its interface needs serious work to
make it usable (and practical) to anyone and everyone.
> I want the select list for existing articles/categories and a text-entry field for "other"/miscellaneous entries
> that don't exist in the "database" yet (but will be once approved.
The idea of having both a dropdown and a text entry for a single field
is one I disagree with, first because I think it's overly complicated,
and second because once you get a large number of options the dropdown
becomes very unwieldy. The combo box solves a number of problems
elegantly, and I think it's a much better solution; and I'm not
planning to implement any "halfway" measures before that one's in.
-Yaron
Second, checkboxes are already supported - you just need to make each
option a separate boolean field.
-Yaron
Please consider creating article-embedded syntax for Semantic Forms
similar to how DPL does it without the need for an extra form. HTML
forms are embedded, for example, and Simple Forms (
http://www.mediawiki.org/wiki/Extension:Simple_Forms ), which I will
be looking at using instead of Semantic Forms once I can get it to
actually work without giving an error, works this way too.
On Jul 22, 7:58 am, Eep² <e...@tnlc.com> wrote:
> > From: "Yaron Koren" <yaro...@gmail.com>
> > Sent: Saturday, July 21, 2007 6:22 PM
>
From: Yaron Koren
Sent: Sunday, July 29, 2007 7:55 PM
Using Semantic Forms in conjunction with Dynamic Page Lists seems like overkill; I don't see what benefit there is in using both. In
any case, it sounds like Simple Forms might be better suited for your needs, so good luck with that.