Matt Whipple wrote:
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.
Interesting. The difficulty I see here is that the definition of various
aspects of the presentation is currently done in the form/fields, and if
I understand you correctly you are suggesting that that sort of
definition should be done in some entirely different object. I am not
really clear on how what you are proposing is different from a template
system, which is basically an external system into which you push your
variables, with a particular template defining the "interface".
You might be interested in the new 'result' object, which separates
static from dynamic but in rather the opposite direction. Only the
dynamic data is stored in the result objects. If you want to render from
a result object it uses the static information in the form/fields to
create the HTML. You can have multiple result objects which all refer to
the same static form. This architecture is particularly suited to
persistent forms.
Gerda
_______________________________________________
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/
