|
|
Posted by Kenneth Downs on 05/05/07 01:20
Henk verhoeven wrote:
> 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.
Hmmm, then this is a point where the frameworks cannot really be compared.
> >
> (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.
Actually that's what I meant. File-by-file comparisons and
cross-fertilization. Should have been more clear.
>
>>
>>> 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.
Untrue in any meaningful way at the application level. Code is imperative,
data is declarative. They cannot be more different. A relational database
can be ACID compliant, transactional, and (of course) relational. Code
canot, whether it is assembly, COBOL or has a spotless OO pedigree.
The seductive power of ORM is the false belief that the disparate natures of
data and code can be glossed over by making one look like the other. Since
one cannot be made to look like the other, the amount of payback for ORM is
negligible except in trivial cases. The more cases you try to accommodate,
the clumsier and bulkier the ORM project becomes.
At this point, many ORM enthusiasts will say, "You can't say that because I
get great payback with my ORM system." My only reply at this point is to
say, "keep going, tell me how it works out 5 years from now."
>
>>
>> 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.
Yeah, the XP stuff is great fun. Great boosk.
>
> 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.
Same here.
>
> Greetings,
>
> Henk Verhoeven,
> www.phpPeanuts.org.
--
Kenneth Downs
www.secdat.com
www.andromeda-project.org
Navigation:
[Reply to this message]
|