Re: The MySQL/PHP pair

"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:19lamc.9j.ln_at_192.168.10.210...
> Dawn M. Wolthuis wrote:
>
> > We also have some agreement
> > (at least I know you agree with me on this one) that we need a means of
> > encoding constraints once for the front-end and back-end "services" to
use
> > the same constraint specifications, or even the same constraint
"engine".
> >
>
> Just jumping in to bang my same old drum.

Yeah, me too, but it still helps to get my own thinking straight as well as hear yours and others again.

> The phrasing "...the same constraint specifications..." is strong because
> the only way to have them both share the same specs is if the
authoritative
> copy of those specs is outside of both.

Yes, agreed.

> Also, it would be much easier to
> do this if those specs were data instead of code.

I also agree with this, however, I see metadata (which constraints are) and code to be two sides of the same coin. All code is metadata as well IMO -- and code can be easier to read, especially if the meta-metadata is not easy to find.

> Also, adding automation to the specs instead of just constraints would
> greatly enhance their value.

I don't understand what you mean by that.

> Less intriguing is the phrase "...or even the same constraint 'engine'".
> This may be a perfectly wonderful idea but I'm having a bad first
> impression. Sounds like trying to reproduce the server on the client,
> which is bad, because only the server can be the server.

I think in terms of clients and services. There are verify-data services today both in the front-end logic and the back-end database. These often duplicate each other, or worse yet, don't. The same service could be used by what you are terming the "server" and by what you might term the "client" (typiclly not ON the client node, however, but on an app server, for example)

> 4 the FAQ: Laconic2 and I have previously come to quick agreement, and I
> believe he beats this drum from time to time, that the client should
> implement any biz rules that can possibly aid and assist the user,
> including some constraints, but that can only cut down on what is
submitted
> to the server, and cannot prevent submissions that ultimately will be
> rejected.
>
> In the spirit of the OP, With PHP and MySQL, implementing biz rules could
be
> limited to the PHP layer, which is the server as far as the users are
> concerned. It that beyond which they may not pass. Putting biz rules in
> the client means the browser. Now it becomes even more important to have
> the biz rules in data if you are going to start supporting all of these
> different platforms.

Yes, I agree that would mean in the PHP -- the middle tier (Java servlets, Perl, etc).

What do you think? Cheers! --dawn Received on Wed Nov 03 2004 - 15:52:43 CET