[jifty-devel] re: Re: design pattern for form table input

Steve H s_t_e_v_e_h at hotmail.com
Sat Nov 10 03:25:39 EST 2007

Hi Todd

> Date: Thu, 8 Nov 2007 16:18:10 -0500
> From: "Todd Chapman" 
> Subject: Re: [jifty-devel] Re: design pattern for form table input
> Content-Type: text/plain; charset=UTF-8
> Isn't that what the Jifty admin interface does? You might want to take
> a look at it's implementation.

I can't see where the AdminUI does what I was looking for.  For example, the rows of records it can update via "Manage records" don't actually provide Input fields (although it does provide the links/buttons on each row)... similarly, the list of Models and Actions on the "Database Administration" page is a list of Links... not Input types, such as .
Maybe there is somewhere else in the AdminUI you had in mind?   The question asked (pasted below) is specifically where a given Input of the same name appears multiple times ... very common for things like radio buttons and check boxes, where any number of those Input types can appear, all with the same Name= ... so, in the case of a checkbox for example, all valies associated with the checked items with that same name= appear in an array in the CGI, for that name=.  In my case, I was wanting to input other types too, e.g. text.  The thing being that browsers only send the input's that have data/values in them... so, unless otherwise provided for, you can come unstuck if any of the items that share that name have no value... as the subsequent ones in the array of values for that name will then be out of alignment.   With checkboxes etc it is usually mitigated by predefined data/value/s that can be returned, whereas with text values, it's user data and up to them... hence typically done by appending a suffix to the Name= so they don't turn up in the CGI as an array against the same name.  ...e.g. you can have input fields called qty_1, qty_2, etc... then look for them in the list of fields given to the CGI via /qty_\d+)/  ...thing is, with Jifty having these things pre-declared in , it seemed to rule out that technique... unless pre-declaring a finite number of them and keeping to that number by Paging everything.  Another way might be to not have Inputs for each row, rather to have a link that will raise some background dhtml to input the data and post it off.
...hence I was asking if there were any Jifty design patterns for this sort of stuff.... as it clearly doesn't handle it "out of the box", given the display of refs on subsequent lines.

> An example might be... a customer chooses an arbitrary number of items... these items then display in a table and can have various data added.... say:
> PartNbr Descr Qty DeliveryNotes
> abc1 some part [ 5 ] [ deliver to the back office ]
> def2 different part [ 3 ] [ leave in the store room ]
> ...where the fields in brackets can have data input.
> If I were to render (via a template/fragment) a table with $action->form_field('Qty'...) and similarly for DeliveryNotes, the second+ rows of the table render for example as text of Jifty::Web::Form::Field::textarea=HASH(0x123abc). I'm used to CGI's providing a table of same-named Input fields returned as an array. Ok, Jifty does it differently... I'm not sure of the design patterns though. In any event (performance pending) I'd be happy to use a handler (e.g. onchange => { args { ...}}) to process it as it is happening. ...or alternatively, how might I be able to get the fields from the various table rows to also include for example some additional info like the row number or some other identification to know to which PartNbr (in the eg above) the input belongs... This is why I was thinking of using a onchange handler to do it, although I don't know what the latency to expect for those sort of calls... and importantly, I still don't know how to differently name the form_field to avoid it rendering as text of Jifty::Web::Form::Field::textarea=HASH(0x123abc), and still be able to refer to it as a known named arg in the action.

Your Future Starts Here. Dream it? Then be it! Find it at www.seek.com.au

More information about the jifty-devel mailing list