Class Structure?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
silence's picture

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

nedjo's picture

[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...

silence's picture

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?

  • Creating the form every time a person clicks the save button or during auto-save.
  • Making a form object in starting and then keep on adding/deleting elements as a person changes the form.

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

nedjo's picture

Actually I was thinking of the internal structure of the page to store the form.

I'm also talking about the internal structure of the data on the page.

As to handling the form object which one do you prefer?

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:

For the data structure, it might be tempting to start from scratch. That way, you could tailor your Javascript code to your usage. But, that would mean you'd need to convert your data structure to a $form array sometime later. Either on the client side, or on the server side.

It would be much better to try and replicate the entire $form array on the client side and manipulate it directly.

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

silence's picture

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

silence's picture

Hi!

I cant find the code corresponding to Form API. Is it in the formproc module?

includes/form.inc

robertDouglass's picture

That's the file that is responsible for the forms API.

Clear language

robertDouglass's picture

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:

A Page has a form and many form elements are created in it.

becomes:

The DOM has a form element and many widgets are created in it.

This leaves no questions about what you're talking about.

SoC 2006: AJAX Form Builder

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: