Hello,
I've been working away on my Template Toolkit branch, and have
recently come to a difficult area, and I think it's important that I
discuss it was as many people as possible. It's about how we currently
represent artists in Perl code. We currently write manual getters and
setters (in CamelCase) which results in somewhat ugly templates.
My current approach has been to add a method called "ExportStash" to
these entities, which creates a hash of properties in the entity for
use in templates. For example:
my $artist = ... load an artist ...
$c->stash->{artist} = $artist->ExportStash;
Then in templates:
Artist's name is [% artist.name %]
This has been a reasonable solution when I began this project, but as
I've been refactoring, it's resulted in having to maintain effectivly
2 copies of entities (_artist which is the actual object, and artist
which is the hash representation) - and this is starting to make the
code a little more confusing than it needs to be.
I've spoken with some Catalyst developers - much wiser than I :-) -
and they have suggested that I write facades for our current entities.
This way I only need to pass the facade around in the new Catalyst
controllers, and it eliminates the need for my weird hash exporting
process.
Now the problem here is that for every entity we have (Artist,
Release, ReleaseEvent, Label, etc...) I have been writing a facade,
and then a model class as well (think of this as glue/syntactic sugar
to use the facade in Catalyst). So for every entity we now have 3
times the amount of classes. This, to me, sounds like a problem.
Another solution, is to rewrite entity classes, so they provide a
nicer interface to the templates. As most of our getters and setters
are one liners, I suggest Class::Accessor here - along with renaming
methods to use perls_naming_covention while I'm at it.
This is going to produce more work, but imo is the cleanest solution.
It depends on how soon you want the TT branch to be completed, I
think. Lukas has mentioned he'd rather see the branch have a cleaner
code base, rather than be rushed out.
I agree, but it's going to make the merges more complicated - Niklas'
work will have been completed, and possibly more features added by the
time my work is complete.
So, I'm all ears for your thoughts. And of course, if anything isn't
clear in the email, feel free to let me know here or on IRC.
- Ollie / aCiD2
_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Contact Details
