Last active
March 3, 2025 19:09
-
-
Save jjn1056/ecc4c1831f6997c60a55396421afabf8 to your computer and use it in GitHub Desktop.
another form builder model example
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sketch to see if we can just use AUTOLOAD to inject into the | |
display object methods as needed ad hoc | |
# in this approach you have some named methods like $args | |
# and other methods use AUTOLOAD, defautl behavior is to call | |
# resolve_method_for_proxy($method) or if that doesn't exist | |
# dfaults to $obj->method. | |
# if you pass args to an AUTOLOADED method, that sets that | |
# method to have that value. | |
my $display_user = $user->proxy | |
->args($c) | |
->first_name | |
->last_name, | |
->dob | |
->state_id | |
->states($c->model('States')->alphabetical) | |
->default_state_id($c->model('States')->default_id); | |
my $fb = ::FormBuilder(model=>$display_user) | |
$fb->input('first_name') | |
$fb->collection_select('state_id', 'states', {default_selected=>$user=>default_state_id}) | |
#same with this, the page object does title and form, uses AUTOLOAD on others | |
page | |
->title($user->naming->human) | |
->list_link($c->uri('../list', [$c->req->args])) | |
->form | |
->model($user) | |
-> | |
Now slightly more complex, where instead of jsut making fiuelds we make objects to | |
more fully encapsulation the form display model. mY biggest issue here is that | |
this seems to be expensive to build it each time. Maybe better to do something like | |
with CatalystX::Request... | |
$user->formbuilder_model | |
->text('first_name', \%opts) # where %opts an be things like active/inactive or even html opts like disabled | |
->text('last_name') # should we allow adding validations here...? Also change the display name via { as=>... } ? | |
->date('dob', \%opts) # lets you do formatting etc | |
->collection_select('state_id', +{ | |
collection => $c->model('States')->alphabetical, | |
default_selected => [ id => 'value', $c->model('States')->default_state_id ], | |
}) | |
and then in the formbuilder | |
$fb->input('first_name') | |
$fb->collection_select('state_id', { class=>'...}) | |
?? How does this work with the request body mapping? And then update or insert? Do | |
we make that separate or put that into this? If we merge it then maybe that argues for | |
a more CatalystX::Request approach | |
That might look like | |
package Example::Model::DisplayUser; | |
has 'first_name' => (is=>'rw', text=>\%opts); | |
has 'state_id' => ( | |
is => 'rw', | |
collection_select => +{ | |
collection => sub($self, $c) { $c->model('States')->alphabetical } , | |
default_selected => [ id => 'value', sub($self, $c) { $c->model('States')->default_state_id } ], | |
} | |
); | |
# in controller | |
my $display_user = $c->model('DisplayUser', $user); | |
# maybe view | |
$self->page | |
->title('user') | |
->body | |
->block(sub ($self, $page) { | |
<div>$page->name</div> | |
}) | |
->form('user')-> | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment