So I think you're right - I think we need to get the EFF on board, help collect a war chest, and defend the next poor bastard they try this with. That way, there will be a clear, established precedent for the next time they try this crap after that.
IIRC, in Britain the loser of a civil suit gets to pay the winner's court costs. We'd have a lot more precedent a lot quicker if that were true here... hmm...
I guess the upshot is that there won't be so many frivolous RIAA cases in Britain.:)
The common lisp part is probably a bit trollish, yes:) but the truth is there. Architectures like J2EE and PHP are very concerned about the mechanics of building the page (very important), but I don't see much structure regarding encapsulating user flow (also very important). True, there are wonderful things such as Struts that move far closer to that goal, but even so you end up managing multiple views, and maybe multiple controllers, when all you really want to say is something like
user = readPersistent(User.newForm(username, password; username == $.username && password == $.password), "Please enter your username and password"); doStuff(user); ...
Ah, well...
As for PHP, I use:
every file includes a common.php that defines your common functions, including one that generates a templated page.
use front controller when I can
data access objects and transfer objects (form and persist), with a nice generic renderer functor s to HTMLize your transfer objects.
data-intensive classes (like transfer objects) usually end up being arrays with type signatures as opposed to actual classes. If you're using your nice generic renderers, adding a column to a result set can boil down to a change in one place. I still call the classes, though, because to me they still are (I do dispatch based on their "type").
I usually use this architecture. DB side: I have a DAO for each table used in a single-table query, along with a specialized DAO for each distinct join situation. These usually pass back a class that knows 1) the data and 2) whether it's a singular or tabular result (whether it was intended to ever bring back multiple rows). I then have a generic result renderer that will render anything, plus any specialized renderers. UI side: I have a generic form class that has a list of labels and references to the fields in the model they represent (or temp field definitions if the fields are not persistent). Then, of course, a generic form renderer + specialized. The rest is usually cookie-cutter.
The caveat here, of course, is that I write mainly business apps, so consistency is the key. The genericity you find all over the place is a win for my kind of app.
Slashdot Mirror
IIRC, in Britain the loser of a civil suit gets to pay the winner's court costs. We'd have a lot more precedent a lot quicker if that were true here... hmm...
I guess the upshot is that there won't be so many frivolous RIAA cases in Britain. :)
As for PHP, I use:
- every file includes a common.php that defines your common functions, including one that generates a templated page.
- use front controller when I can
- data access objects and transfer objects (form and persist), with a nice generic renderer functor s to HTMLize your transfer objects.
- data-intensive classes (like transfer objects) usually end up being arrays with type signatures as opposed to actual classes. If you're using your nice generic renderers, adding a column to a result set can boil down to a change in one place. I still call the classes, though, because to me they still are (I do dispatch based on their "type").
I usually use this architecture. DB side: I have a DAO for each table used in a single-table query, along with a specialized DAO for each distinct join situation. These usually pass back a class that knows 1) the data and 2) whether it's a singular or tabular result (whether it was intended to ever bring back multiple rows). I then have a generic result renderer that will render anything, plus any specialized renderers. UI side: I have a generic form class that has a list of labels and references to the fields in the model they represent (or temp field definitions if the fields are not persistent). Then, of course, a generic form renderer + specialized. The rest is usually cookie-cutter.The caveat here, of course, is that I write mainly business apps, so consistency is the key. The genericity you find all over the place is a win for my kind of app.