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
