Re: [Pas-dev] Dependency objects and data serialization
Status: Beta
Brought to you by:
mortis
From: Kyle R . B. <mo...@vo...> - 2002-03-13 15:18:50
|
> Last night I spent some time and got started on the dependency object > creation. Any objections to RequestHandler using Data::Dumper? I didnt > see a generic serialize_data method, but I may have been grepping in the > wrong place. Session.pm had some stuff that was close to what I wanted, > but its not reusable. Since it's the compiler that is the entity that discovers the dependency list, perhaps we should add a method to the compiler which constructs our dependency object for us? my $depInfo = $compiler->getDepInfo( $pspFile ); Which (at least for now) could be as simple as: sub getDepInfo { my($self,$file) = @_; my $dep; eval { $dep = do $file; }; if($@) { $self->throw("Exception loading dependency info from '$file' : $@\n"); } return $dep; } hrm...maybe that should be instead: sub getDepInfo { my($slef,$file) = @_; return Org::Bgw::Pas::Psp::Dependency->newFromFile( $file ); } Where: sub newFromFile { my($pkg,$file) = @_; my $dep; eval { $dep = do $file; }; if($@) { die("Exception loading dependency info from '$file' : $@\n"); } bless $dep, $pkg; return $dep; } Serialization, IMO, should also be encapsulated in the Dep object: use Data::Dumper; sub saveToFile { my($self,$file) = @_; $self->writeFile( $file, Dumper(\$self) ); } > Would we benefit by having a $base->serialize_data(\$obj,\$d); method? You can basicly call Data::Dumper in 1 line of code (even if you want to twiddle it's parameters). I don't see serialization being core enough to the application to warrant it being in the base class. Where else can we see it being used? Session, Dependency, and what else? > Pass it a thingy and a scalar ref, it fills the ref with a serialized > thingy. This would be a more generic thing that the other objects could > take advantage of. This way RequestHandler doesnt 'know' about what > we're doing to the dependency object, I'm all for keeping the request handler in the dark about as much as possible -- unless it's something the request handler is directly responsible for. It'll keep the code simpler, cleaner and more maintainable. The less coupling we have in the objects in Pas the better. > and if I ever want to store a > serialized thing in a database or ldap, there's a simple way to get the > data formated. If we go this route, we could refactor Session.pm to use > it. Along with a $base->deserialize_data(\$ref). > > What do you think? Am I over complicating this? Should I just do a > simple Dump, write file? > > Nice trick with ->readFile btw. I like it. I think we also did a ->writeFile(), and a [my $fh = $self->openFile()]. All which throw exceptions when things go wrong. It's just basic abstraction/refactoring, but it help keeps lines of code to a minimum, which makes things easier to read and maintain. I think you're on the right track -- thanks for bringing it up on the list for discussion before diving in. Regardless of how you decide to do it, at least we've got a handle on how it will fit in to the rest of the code. Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |