Developing using RDGC
mackler
already: how best to use RDGC as a development tool.
The basic issue is that RDGC is automated, and it only goes so far.
So once one starts modifying the scaffolding it produces by hand, one
risks losing that labor the next time the Garden is planted.
I would be interested in making a comprehensive assessment of the
various approaches one could take when dealing with this situation.
Here's what I've gathered so far from Peter and my own thinking:
1. Do as much toward completing your database before making any hand
modifications to the RDGC-produced scaffolding. Several of what I
thought were "bugs" in distributed modules disappeared just by
normalizing my database structure.
2. Use whatever configuration abilities RDGC has to automate the
planting process as much as possible. I see from the docs there are
things called init_base_code and init_base_form_class_code. What else
can one do in the script that calls plant to cause the resulting
application to need as little hand modification as possible? Is there
any way to affect just one class--for example to insert code that
provides an appropriate unique_value method? I'm hoping the Author
will be able to provide any information about more ways to customize
the behavior of the planting process.
3. After you modify the scaffolding by hand, save the changes somehow
so you can apply them again after running plant. Since I'm trying to
do things as automatically as possible, reapplying changes by hand is
not appealing, but there may be ways to automate this using sed or
something.
4. Another idea that came to my mind is to use the output of RDGC as
guidance for building my own application. All my work done by hand
would be to my own application, and rerunning plaint wouldn't affect
what I've done. I haven't tried this yet, just had the idea.
Basically I have two problems at the moment: one is that I'm using
RDGC for the first time, and the second is that I am also creating my
database at the same time. While I may not have the first problem
again, each database-driven-website project will likely begin with a
period during which the database is changing, and anything generated
using plant will have to be replanted.
So far I've tried to do NO manual modification of my scaffolding as I
build my database, but I'm reaching the limit of what plant will do.
In particular, it seems that enum types are not detected as such, so
that the field type is not a pull-down menu, nor is there any Form
validation to make sure the value provided is one the database will
take--this will consistently cause errors without validation code
added. (If there's a way to get enums to be handled that way I'd love
to know, but it's looking like dealing with those will be the first
hand-modification my development process will apply after running
plant.)
So right now I have a script that I run not just to call plant, but to
do everything starting with creating the Catalyst application, all the
way up to installing all the YUI template files. It's great. I love
it. And the further I can go in developing this script so as to
preserve my ability to regenerate everything I've done that far with a
single command line, the happier I'll be.
Adam
Peter Karman
> 1. Do as much toward completing your database before making any hand
> modifications to the RDGC-produced scaffolding. Several of what I
> thought were "bugs" in distributed modules disappeared just by
> normalizing my database structure.
That's a nice side effect then.
>
> 2. Use whatever configuration abilities RDGC has to automate the
> planting process as much as possible. I see from the docs there are
> things called init_base_code and init_base_form_class_code. What else
> can one do in the script that calls plant to cause the resulting
> application to need as little hand modification as possible? Is there
> any way to affect just one class--for example to insert code that
> provides an appropriate unique_value method? I'm hoping the Author
> will be able to provide any information about more ways to customize
> the behavior of the planting process.
Remember that Rose::DBx::Garden is a subclass of
Rose::DB::Object::Loader, so you can pass any of the same arguments to
new() for the Garden as you can for the Loader. Look at the docs for
"module_postamble" for example.
If you didn't want to touch the Loader features, the ability to
specify base class code could be used to monkeypatch your generated
classes during development. That way your modifications would all be
localized in your plant.pl script, and you wouldn't have to modify any
generated files.
You could do something like this for example:
my $base_rdbo_code =<<EOF;
# monkeypatch generated classes
sub MyRoseGarden::MyDB::MyTableClass::unique_value {
return shift->full_name;
}
sub MyRoseGarden::MyDB::MyTableClass::full_name {
my $self = shift;
return join(' ', grep { defined } $self->first_name, $self-
>last_name);
}
EOF
my $garden = Rose::DBx::Garden->new(
base_code => $base_rdbo_code
# etc
);
$garden->plant();
>
> 3. After you modify the scaffolding by hand, save the changes somehow
> so you can apply them again after running plant. Since I'm trying to
> do things as automatically as possible, reapplying changes by hand is
> not appealing, but there may be ways to automate this using sed or
> something.
Sure, you could post-process the generated files. Or see above about
the Loader features.
>
> 4. Another idea that came to my mind is to use the output of RDGC as
> guidance for building my own application. All my work done by hand
> would be to my own application, and rerunning plaint wouldn't affect
> what I've done. I haven't tried this yet, just had the idea.
Yes, you could always maintain other Catalyst Model classes that
subclass the generated files and then override and extend them. For
example:
lib/MyApp/Model/MyUser.pm
could be a subclass of
lib/MyApp/Model/RDGC/MyDB/User.pm
and you could replant all you wanted, since MyApp::Model::MyUser has
all your non-generated code.
>
> Basically I have two problems at the moment: one is that I'm using
> RDGC for the first time, and the second is that I am also creating my
> database at the same time. While I may not have the first problem
> again, each database-driven-website project will likely begin with a
> period during which the database is changing, and anything generated
> using plant will have to be replanted.
RDGC was actually created to solve that problem. It's ideal (IMO) for
rapid schema development, when you want to be able to see how things
hold together while you're tweeking the db definitions.
>
> So far I've tried to do NO manual modification of my scaffolding as I
> build my database, but I'm reaching the limit of what plant will do.
> In particular, it seems that enum types are not detected as such, so
> that the field type is not a pull-down menu, nor is there any Form
> validation to make sure the value provided is one the database will
> take--this will consistently cause errors without validation code
> added. (If there's a way to get enums to be handled that way I'd love
> to know, but it's looking like dealing with those will be the first
> hand-modification my development process will apply after running
> plant.)
enum wasn't hard to add. I just put it into svn trunk here:
https://svn.msi.umn.edu/sw/perl/Rose-DBx-Garden/trunk
You can see the changeset here, to see how straitforward it is to add
column/field mappings:
https://trac.msi.umn.edu/trac/sw/changeset/608
Let me know if that Enum feature works as expected and I can push 0.16
Garden to CPAN.
>
> So right now I have a script that I run not just to call plant, but to
> do everything starting with creating the Catalyst application, all the
> way up to installing all the YUI template files. It's great. I love
> it. And the further I can go in developing this script so as to
> preserve my ability to regenerate everything I've done that far with a
> single command line, the happier I'll be.
>
Cool. Glad to hear it is working well for you. And thanks for the
thorough and well-considered emails.
pek