Hey,
So there's a change (https://gerrit.wikimedia.org/r/48995) that's adding a new subclass to HTMLForm, so I had a quick question for whoever has more experience with HTMLForm than I do. The new subclass will always output a table for the getInputHTML(), even if the parent form is set to div/raw output. Is this OK, i.e., is the table/div/raw only applicable to the form itself, or should the subclass make sure to follow that format as well? Unfortunately, there is no precedent for this because every other field type only puts out an input tag.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Hey,
The new subclass will always output a
table for the getInputHTML(), even if the parent form is set to div/raw output.
That very much sounds like a violation of the Liskov substitution pattern. In other words, it sounds like code using an instance of HTMLForm might run into problems when this instance happens to be of the type defined by the new subclass.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
Tyler left out a critical piece of information: This new subclass is for constructing a matrix of checkbox options in a form. You feed it a list of row labels and a list of column labels and it constructs a table of checkbox options:
Category 1 Category 2 Category 3 Option 1 [ ] [ ] [ ] Option 2 [ ] [ ] [ ] Option 3 [ ] [ ] [ ]
The suggestion that this should be constructed with divs (or no formatting at all) rather than a table is silly. The setDisplayFormat function in HTMLForm is for setting the formatting of the form itself, not dictating what HTML can and can't be use in the individual elements of the form. The description of the function reads: "Set format in which to display the form". If the display format is set to div, the new subclass put the element in a div. If the display format is set to table, it puts it in a table. If the display format is set to raw, it doesn't put the element in anything. This is identical to the functionality of every existing subclass in HTMLForm. The only difference is that the form element itself happens to be a table rather than an input. Blocking this feature simply because it uses a table doesn't make sense to me. The table doesn't cause any problems in any actual output formats. I've tried it in MobileFrontend (with the form set to raw mode), for example, and it looks fine. I think the purpose of the setDisplayFormat function is being misunderstood in this case.
If anyone is familiar with HTMLForm, please feel free to weight in at https://gerrit.wikimedia.org/r/#/c/48995/.
Ryan Kaldari
On 2/21/13 2:41 PM, Jeroen De Dauw wrote:
Hey,
The new subclass will always output a
table for the getInputHTML(), even if the parent form is set to div/raw output.
That very much sounds like a violation of the Liskov substitution pattern. In other words, it sounds like code using an instance of HTMLForm might run into problems when this instance happens to be of the type defined by the new subclass.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'm fine either way with this change. I was just hesitant because I wasn't sure whether HTMLForm was designed in a matter where front-end developers were expecting all divs.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
I think Kaldari's approach actually makes sense and does not conflict with the available output formats of HTMLForm. The HTMLForm output formats are intended holistic for the whole form, rather than requiring a specific format for each form element. It would be ideal if all elements were output in the same format (div vs raw vs table), but I think there are instances where it is acceptable to deviate from that, and this seems like one of those instances. Given what Kaldari is trying to achieve, I think his approach is sensible, unless there is a reasonable (relatively straightforward/simple/elegant) solution for the checkbox matrix that does not involve wrapping it in a table.
On Sat, Mar 2, 2013 at 4:44 AM, Tyler Romeo tylerromeo@gmail.com wrote:
I'm fine either way with this change. I was just hesitant because I wasn't sure whether HTMLForm was designed in a matter where front-end developers were expecting all divs.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Mar 4, 2013 at 1:46 PM, Arthur Richards arichards@wikimedia.orgwrote:
I think Kaldari's approach actually makes sense and does not conflict with the available output formats of HTMLForm. The HTMLForm output formats are intended holistic for the whole form, rather than requiring a specific format for each form element. It would be ideal if all elements were output in the same format (div vs raw vs table), but I think there are instances where it is acceptable to deviate from that, and this seems like one of those instances. Given what Kaldari is trying to achieve, I think his approach is sensible, unless there is a reasonable (relatively straightforward/simple/elegant) solution for the checkbox matrix that does not involve wrapping it in a table.
Mhm, makes sense. Honestly I just want to be sure it doesn't break anything, i.e., if a caller wants div output or raw output, is there any reason this would be unexpected. I'm asking mainly because I really have no idea under what circumstances or for what reasons a calling function would want div/raw format.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
wikitech-l@lists.wikimedia.org