TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
New Form Manager module for Kohana 3.3
  • Hi Guys,

    Just wanted to let people know that we've been working hard on a new Form manager module for Ko3.3 (i know, another Form module!), and now it's complete, I'm happy to offer the module to the community. We've spent quite a bit of time making sure this one works just how we want it, and there's plenty of documentation available (as a work in progress guide + API docs).

    It aims to take on a similar objective that Zend_Form (for Zend 1.x) was used for (although its a lot easier to use!), and has a lot of support for easily managing views (with cascading theme support), sub forms, highly complex field types, file uploads and a whole host more).

    The repo is available at https://bitbucket.org/temperedvision/kohana-modules-form, so please feel free to poke around, fork, ask questions, raise issues etc. The module is commercially backed (as we use it internally) so its in our interests to ensure it runs well.

    Also, rather than trying to think of catchy names for the module, its simply called "Form" (why would you need another Form module?).

    Final note, we purposely have not linked the Form module to any ORM as we firmly believe that the data access layer provide by a model should have no direct relationship to the presentational layer. Therefore, you have complete flexibility on what you do with the data (DB / ORM, webservice etc etc).

  • Finally another non-ORM form system. Can you post an example usage code, I'm curious how you handle your interface?

    Also I was looking at the code. At one point in my own implementation of a Form helper I also had a class for every little pesky field, but found that approach to be awkward, unintuitive (ie. designers don't like to write classes) and hardly ever needed to use the class functionality. So in a recent iteration I've simply had the form have a single method field that accepts a type and map the intracacies in a configuration file (see fieldtypes). I still have the syntactic sugar methods, but this approach allows me to skip over having classes for fields I only need to have their type change. Just some food for thought.

  • Sorry Akki, it seams I didnt have email notifications turned on, so didn't notice your comment.

    For example code, a number of isolated examples can be found in the guide as we've tried to be relatively thorough with the documentation. However, I've just added an example app with some working code (with various amounts of customisation so you can some of the features) at https://bitbucket.org/temperedvision/kohana-modules-form-example.

  • By moving the validation to the form instead of keeping it separate, aren't you duplicating the validation every time you change the form ever so slightly and place it somewhere else? Also isn't it adding a lot more overhead to creating a form, since you kind of have to create the entire class system each time to write all this validation, which isn't really necessary otherwise since the code would be pretty generic (or shouldn't be anyway).

    Another problem I would see in that approach is that I believe it breaks encapsulation. Unless you treat your forms as (for the lack of better wording) your "models". Sometimes you may have a very complex structure that isn't say linked to any one table or such (I personally see that all the time), so you have to rip any complexity and stick it into your form, creating a sort of weird dependency chain that may drive anyone doing maintenance crazy. :)

    Another thing I find weird is how you add elements into a form tag. I'm guessing that's so you can have everything inside a <form> element? If so how do you create the following structure: a table with checkboxes to select items (checkboxes have the name selected[]) with mini forms with actions for each item in the table, follow by a set of actions at the bottom of the table that are linked to the checkboxes. You can't have forms in forms, and I'm not sure how you would deal with having lots of mini forms on a page with that system.

    Looking at the classes I also think you're missing an option for composite fields, things like label: [text] [text] (to give a really crude example) are really common (just think of how often you see the whole [First Name] [Last Name] pattern).

    Some other minor things,

    • how would you go about custom layout forms (tabed forms, forms in multiple columns, etc)
    • how do you create a <button> submit buttons (don't think I ever write regular submit buttons)
    • I might be mistaken but I think your checkboxes are actually on/off switches and not based on the value of the input? ie. if checked the value is passed, otherwise the value is not passed
    • why no date, datetime, datetime-local fields?
    • you don't manage tabindex?
  • code samples?

  • See the links in the previous posts. Working code samples are included as well as a range of documentation examples

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion