Re: Getting a New CDBI object without creating one in db?

[prev] [thread] [next] [Date index for 2004/10/19]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



William Ross wrote:
| On 19 Oct 2004, at 11:26, Tony Bowden wrote:
|
|> On Tue, Oct 19, 2004 at 10:16:09AM +0200, Andreas Fromm wrote:
|>
|>> The problem I have is when I want to access field names linked by has_a
|>> fields, e.g.
|>> MyClass::Person  has fileds: [name, surename, address]
|>> but MyClass::Person->has_a( address => MyCLass::Addresses )
|>> in that case I can't get the fields of MyClass::Addresses if now object
|>> of Person has been instantiated.
|>
|>
|> I still don't understand.
|>
|> Do you want to pre-populate the box with all the entries in Addresses?
|> If so, then you can get that relationship from the Peron class, and call
|> retrieve-all on it.
|>
|> If you're looking for a particular address, then that doesn't make sense
|> unless you already have an object.
|
|
| I think the issue here is probably that under TT it is alluringly easy
| to go through a sequence like this:
|
| You write a form full of these, with which to edit your CDs:
|
|     <input type="text" name="title" value="[% cd.title %]">
|     <input type="radio" name="is_annoying" value="1"[% ' checked' IF
| cd.is_annoying %]>
|
| Then you decide to use the same form to create new cd objects, since it
| already has all the fields and buttons you need. You want to populate
| some of the form fields in advance, perhaps with defaults or input
| values, so you have a few choices:
|
| * you can stick a load of conditionals on the form: [% cd.title ||
| input.title || class.default_title %] (leaving for now the question of
| where the [% class %] variable comes from, which is a problem I never
| managed to solve nicely).
|
| * you can stick a load of conditionals in your handler to do essentially
| the same thing but keep the templates simple.
|
| * you can pass through a [% cd %] hashref object of default values and
| rely on TT's helpfully ambiguous dot operator to keep the template simple.
|
| * you can pass through a [% cd %] object that acts like a cdbi data
| object, at least as far as the template requires it to.
|
| I've always gone for the last option because it keeps the templates
| readable and the handler simple, and draws the line between template
| authors and handler authors in about the right place, imo.
|
| (I also use the same ghost mechanism to hold information about an object
| after it has been deleted, in order to be able to refer to it on the
| confirmation page.)
|
| I think there may be an interesting split in the way cdbi is used and
| thought about, with template-led people taking this kind of course and
| more strictly pipelined people passing through carefully-prepared data
| bundles. This conversation certainly sounds like its participants come
| from a very different assumptions about how cdbi works with templates...
|
| best
|
| will

actually, I don't have a ready form to populate, but was doing things
like this:

foreach my $field ( $person->all ){
~  if ( UNIVERSAL::isa(ref $person->$field, 'Class::DBI') ){
~    .... do something with the referenced class fields ...
~    .... for example:
~      foreach my $subfield ( $person->$field->all ){
~         ....
~      }
~  } else {
~    .... do something with the fields, ....
~    .... for example write a form input ....
~  }
}

The test for UNIVERSAL::isa(ref $person->$field, 'Class::DBI') will
never be true if the object isn't instantiated. What I did then was to
creacte an empty object, populate everything with 'undef' and then
discarded the object once I had the structure with all the references of
the fields, but thats clearly not an efficient way of doing things.

- --
Grüße,

Andreas Fromm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBdQA7UmBtSMq5cGURAsQTAKCFivLv5sJxmZrLQbcLpDNcKX793wCfasQC
+HnvUlmmXbU79XT/xsEYesc=
=YcE1
-----END PGP SIGNATURE-----