Posted by Henk verhoeven on 05/01/07 21:35

Kenneth Downs schreef:
> Henk verhoeven wrote:
>
>> Kenneth Downs wrote:
>>> (..) the trouble doesn't start until you put in the filters. At
>>> this point we punted on that and are having using enter SQL expressions
>>> like "dob < '1990-01-01'".
>> Interesting, i have learned to think of SQL injection as a security
>> breach, you seem to be doing it on purpose**
>> ** Yes, i read your remark on this subject on
>> http://www.andromeda-project.org/pages/cms/SQL+Injections
>> It seems to me that you do not expect application developers to extend
>> the security beyond what can be arranged on the database.
>
> Henk, thanks for the reply, it is always a pleasure to talk shop with
> another framework author.
Thank you for yours too, it is interesting.
>
> We probably need lots of discussion on the different assumptions between
> Andromeda and phpPeanuts before we can draw conclusions.
I agree. I am not trying to draw conclusions. The differences are
interesting enough.

> That being said,
> I suspect, based on your remarks, and on prior experience, that your
> framework connects to the database as a super-user and your code (or
> application code) handles security.

Well, yes and no. Yes, the default is to log in using settings made in a
settings script. I don't think that is a good thing, just seemed the
simpelest think that could possibly work. It can be overriden and i have
done so in several occasions.
No, my framewok has not got a built in security component. There's only
an example pointing in the direction of how to use the front controller
to check security, and a discussion about how to go on from there. So
security is basically left to the application developers.
>
(snip)
>
> Two issues here. First is the GPL. My intention for licensing is that
> applications are not considered derivative works, so I am investigating
> whether I should switch to LGPL. More on that later.

If fpdf is under GPL instead of LGPL that may not be an option for those
parts that require fpdf.
But if your applications are not written in php but in this declarative
language i see in your tutorials i don't think there is a problem for
the applications, as long as no 'linking' takes place. Of course a JIT
compiler would blow this distinction to pieces, but so do RPC & SOAP...
>
> Second issue is merging/combining. Who knows? Hard to say until we've
> looked at each other's code.

I do not intend to merge. But there may be opportunities here and there
to reuse things, maybe design concepts, or maybe code. I agree that that
does require a lot more study. I intend to do some studying in the near
future, of several frameworks, to see what is available, and how to go on.

>
>> Furthermore, phpPeanuts is object-oriented, mapping the object's data to
>> database records.
>
> I first got into OO in the 90s, developed OO mania late 90s/early 2000s, and
> can now say, "been there, done that, not interested". The inescapable trap
> of OO framework development is assuming that code is a lasting asset, and
> that if it could only be structured right, it would have lasting value, it
> would at long last be "reusable." But it just ain't so. Code expires.
Absolutely.

> Data survives.
But from an OO point of view there is no difference between data,
objects and code.

>
> Now, once a person has seen the design cycle 2 or 3 times and realized that
> the entire framework is doomed, he looks for something that will survive
> the sea changes. This puts a person in the frame of mind to examine the
> first fact of Andromeda: "All business rules resolve to database
> specifications." From here we realize that what lasts is a description of
> the business rules, which is nothing more than a description of the
> database. (IF, and its a big IF, if you can work out what that description
> itself must look like). The creative act in writing Andromeda was not the
> coding, but describing the description.

Interetsing, i will certainly look into it later this year.

PhpPeanuts is third generation. I did look for something that could
survive too, but for me it where concepts that went into the designs. In
fact i did spend very litte time designing phpPeanuts when i started. I
started the eXtreme Programming (XP) way, building a first application
and the framework allmost simultaneously. I agree the application would
have been finisshed much earlier if i had not built the framework, so
according to XP i should not have built (most of) the framework, but i
had an idea of what the framework had to do, and i still think i built
the simpelest think that could possibly do that.

>
> This also leads to another huge difference between Andromeda and the others,
> we have precious little code in the framework. The builder is about 6000
> lines and the entire framework is another 10000, and we work hard to keep
> the line count low. Minimize code, maximize data.

I agree about keeping the amout of code low. Last beta is about 22200
lines of code (excluding examples, templates, styles and a javascript
include file). I think i can do with less code then many other
frameworks because the framework often implements a simple solution and
leaves it to the application developer to override it when he needs to.
>
> As I said before, there are so many differences in our approach that simple
> things like "object oriented" require considerable conversation before we
> can get at why you went one way and I went another.

I the my for why i went the OO way is simply "Smalltalk".
>
>
>
>> This allows one to add functions written in php to the
>> domain model, navigate it, build and maintain hierarchies and have
>> polymorphism. OTOH, If you want the freedom to JOIN and GROUP BY, the
>> table-oriented aproach of Andromeda will probably suit you better.
>
> None of those features require OO. In fact, nothing *requires* OO.

Of course, the essence of OO is a few concepts, technically it's nothing
but data references, function references and a type hierachy. Anything
can be expressed with those. I use OO allmost because i grew up with it.
(Allmost, i did first learn procedural & structured programming, but
that now is a long time ago). I think the best feature of OO is
flexibility. If it's applied properly, of course.

To optimize for flexibility i do on purpose not make a distinction
between declarations (which i guess you call 'data') and code. Code that
is imparative in the current version of the framework may be replaced by
more generic code and some declarations later on. A later version of the
framework will probably allow the replacing of imparative application
code by more declarative code. But the other way around, code that is
declarative in the default implementations provided by the current
framework or the programming style shown in the examples may in a
specific application or in a later version of the framework be replaced
by a an imparative implementation, or by some code that does a database
query, some specific objects that model whatever however they like, or
maybe even by an implementation of a domain specific language, as long
as it produces the same kind of results. Or maybe even quite different
results that just happen to make sense to whoever lives then.

I got the impression our assumptions are quite different. To me it is
still interesting though to see what you are doing. Thanks for your
reaction.

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

[Back to original message]