Hi!
As I mentioned in my mail, I had a problem with the design of the page. I'll describe it a bit more here:
A Page has a form and many form elements are created in it. Each of the form element has different properties as described in form API. So basically, I need to keep track of the elements, the properties which correspond to these elements and their values. These need to be organized in some object oriented manner. And I could not find a good way to do it.
The only way I could think of was by having three classes namely: Form, Item, Properties. Now each page creates a Form object and all the additions and deletions of items are done from this form object. The Object also has property called itemList which is a array of object type Item. Now Item class, based on the type sent in constructor asks the Property class for all the properties corresponding to a particular element type and accordingly makes the object.
Here's a representation of what I am talking:
Form
- Item itemList[]
String Title
String Description
...
Item
- Static addItem(itemType)
Static removeItem(itemNumber)
changeProperty(propertyName: value)
getProperty(propertyName)
...
Properties
- propertyRef[][] - basically a 2x2 matrix having the mapping of which element has which properties(as given in Quick Guide)
getProperties(elementType)
...
I dont know how much of this is good or makes sense.... Please comment.
just for ease, here's the location where I'll maintain a working page: http://freewebs.com/socdemocode/prototype0
Comments
Use the $form array directly
[editing to correct the most glaring mistakes in my draft code ;)]
Avi, I think you're basically on an okay track. And, while I'd second Robert's earlier advice that it's more important to focus at this stage on the basics, it's nonetheless good to see your draft interface.
As to the structure, rather than creating a different structure, I think we need to use the Forms API $form array structure directly. Here's a very basic example of how that could be done.
function DrupalForm(form) {
this.form = form ? form : {};
this.addElement = function(key, properties) {
this.form[key] = properties;
}
}
var form = new DrupalForm();
form.addElement('name', {'#type': 'textfield'});
If, for the UI, you need to add additional properties, you could do so as new selectors, e.g., '#whatever'. Then, when it comes time to save the data as a form array, we can strip this out first.
Clarifications...
Actually I was thinking of the internal structure of the page to store the form. Once the form building is done, person clicks a button or something and the form structure is generated.
As to handling the form object which one do you prefer?
As far as I can see, the first method is slow as it creates the object every time we need to save it. On the other hand, the latter option can make things difficult for me and be a little uncleaner.
I would prefer using the first option if there are no compelling reasons for the latter. So basically the Form class I was taking about in the main post will also have a getFormObject() kind of a function which creates what we finally need - the form Object in a format like thins:
$form['foo'] = array(
'#type' => 'textfield',
'#title' => t('bar'),
'#default_value' => $object['foo'],
'#size' => 60,
'#maxlength' => 64,
'#description' => t('baz'),
);
.
Recall the original planning docs
I'm also talking about the internal structure of the data on the page.
While I can see the potential attraction of the first option, the second is definitely what we need to shoot for. This was the central point of the XML/XSLT vs. JSON/JS discussion. We need to be directly manipulating a data structure that directly represents the $form array.
Recall that from the outset the suggested approach has been to use the $form array directly as the data structure. See the suggested approach that Steven wrote:
Unless there is a very compelling reason to do otherwise, we should be manipulating and rendering a JS version of the $form array. Recall that in a later stage we will need to be loading and changing existing forms. I can't see that there's anything gained by doing all this work in a different format. We already have an established format for form data: the $form array. Using that directly will greatly simplify things.
I think I got the point now
I think I got the point now :). The second way gets simplified a lot with the help of Form API code. I'll, hence, manipulate and render a JS version of the $form array :).
So basically, I'll start with the task... I'll look at the form api code and post any difficulties found in it in this group.
Meanwhile, I commited the initial code in directory: modules/formbuilder. Please see if the format is correct.
The Jquery files are here: http://freewebs.com/socdemocode/js.zip (the link is there in the readme.txt)
Lost
Hi!
I cant find the code corresponding to Form API. Is it in the formproc module?
includes/form.inc
That's the file that is responsible for the forms API.
Clear language
Hi Avi,
I'd like to suggest that we agree on some language conventions for talking about this stuff, because the words "object" and "form" and "page" just aren't going to keep things clear. Reading the above discussion for someone who wasn't there from the beginning is impossible.
When talking about a Drupal $form, which is an array of PHP attributes and part of the forms API, it is probably easy enough to say "$form". When talking about a DOM/HTML form on the client, I suggest we say "DOM form". There are no pages. There is "the DOM". Then, when we use the word "object", please lets clarify "PHP object" or "JS object". Text fields, radio buttons, check boxes and the like are "widgets".
So with these suggestions, your first sentence from above would get rewritten:
becomes:
This leaves no questions about what you're talking about.