Hi, I'm a recent adopter of HFH, and was drawn to it partly in hopes of
having a decently clean solution for form rendering (I've begun a system
but don't think it will be usable anytime in the near future) so I'll
contribute my 2 cents.
From my perspective the output/rendering of the form data normally
represents a static view of the data, a single state which will
generally not require any return communication with the system which
renders it. I therefore see a more independent treatment of widgets the
best option to allow those widgets to fit into the most places, and be
made the most accessible for future growth. Rather than treating the
widgets as roles to be pulled into the form system, they could be
external objects with a common interface which are pushed into and piped
from. This aids in separation of concerns and could lead to afar more
flexible, robust widget framework which is more conducive to
collaboration and extension within and without the larger system.
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
