Re: RFC WWW::Arbeitsagentur
First of all, great idea :) Ingo Wiarda schrieb: =head1 SYNOPSIS ... path= download/, # where to save the job descriptions I personally find it more easy to understand to place the comments _above_ the code, as the reader then first sees _what_ you're doing and after that _how_ you're doing it. The details should follow the overview and not vice versa IMHO. Search results are collected and may be filtered and stored temporarily for offline-use. _May_ be stored or _must_ be stored on disk? As you supply a storage path in the example in the synopsis, it does a bit look like that it has to be done like this. Are there also options to just get everything in a perl data structure without storing it in a directory on disk? This way one could e.g. save it in a database instead of some files on a disk. -Thomas
Re: RFC WWW::Arbeitsagentur
Am Samstag 24 Juni 2006 23:51 schrieb Thomas Wittek: path= download/, # where to save the job descriptions I personally find it more easy to understand to place the comments _above_ the code, as the reader then first sees _what_ you're doing and after that _how_ you're doing it. The details should follow the overview and not vice versa IMHO. Good point. Search results are collected and may be filtered and stored temporarily for offline-use. _May_ be stored or _must_ be stored on disk? As you supply a storage path in the example in the synopsis, it does a bit look like that it has to be done like this. Results may be stored on disk, the path is not mandatory. Is it better to write more examples in the Synopsis (one with, another one without a path argument) or just to expand the comment like: # where to save your files (optional) path= download/? Are there also options to just get everything in a perl data structure without storing it in a directory on disk? This way one could e.g. save it in a database instead of some files on a disk. The filter modules can parse a result page and return an Applicant or Job-object. As to storing those in a database - it is possible to do this, but under german copyright law and the site's EULA, you are probably not allowed to. The parent project for this module (arbeitssuche.sf.net) stores all pages on disk and parses them on the fly before presenting the relevant elements. If you decide to filter a search result, the file will be removed and only the reference-number will be saved. This way, it is possible to claim that the programm works like a browser (download result, cache it, show it, delete it) and thus will not break local copyright law... Another question is how to name variables / attributes. The web forms on the site have german strings: input type=text name=eintrittsterminString ... So, should I use this so we get $applicant-eintrittstermin or translate it to something like $applicant-date_of_entry? Ingo
Re: RFC WWW::Arbeitsagentur
Ingo Wiarda wrote: Results may be stored on disk, the path is not mandatory. Is it better to write more examples in the Synopsis (one with, another one without a path argument) or just to expand the comment like: # where to save your files (optional) path= download/? Should be enough, if the full documentation of the method WWW::Arbeitsagentur::Search::FastSearchForWork-new makes it clear. Another question is how to name variables / attributes. The web forms on the site have german strings: input type=text name=eintrittsterminString ... So, should I use this so we get $applicant-eintrittstermin or translate it to something like $applicant-date_of_entry? That's a good question. On the one hand, CPAN is an international place and using german method/attribute names might not be a good idea. On the other hand it's relatively unlikely that any non-German would use this module. To be consistent with the other modules on CPAN, i'd personally prefer using english names, especially as you're already using english words in your package names (..::Search::FastSearchForWork). -Thomas
Re: A Semi-Public Version Control Repository for Your CPAN Modules
Shlomi Fish wrote: Now, Adam Kennedy recently made an interesting step of making commit access to a Subversion repository with the source code for most of his modules to anyone with a valid PAUSE login: http://use.perl.org/~Alias/journal/29327 My suggestion is for you to do something similar. What do you think? Is there any reason for you not to do so? Shlomi, Another option is to just upload the distribution with your changes using your own PAUSE ID to cpan. It will not get indexed, but succeeds in that users who don't know about or trust some external repository can still access your changes via the CPAN network. If you are in Europe in August, you might like to come to YAPC and see the announcement of cpan6, this concern is included in the design requirements and making small changes to other's code will be natural and safe. http://www.birmingham2006.com/cgi-bin/yapc.pl?act=talk-itemtalkid=51 Sam.
