|
|
Posted by gerald Zincke on 11/24/12 11:54
That's a good answer, Kenneth wrote here.
My experience is, that most people writing PHP are using it just to pep up
their web pages,
which is quite a different task compared to writing a real web application.
If you get serious with web applications (information systems, complex data
models, large databases, transactions, and that stuff)
you probably need an application framework with a good metaphor behind it.
For instance it must allow to synchronize
user transactions with database transactions.
If you like the idea that a web application should not re-invent the GUI
wheel
but should support a dialog flow similar to what we are used to at the
desktop,
you may like the GGF Framework (http://de.geocities.com/ggf_team/).
regards
Jerry
"Kenneth Downs" <knode.wants.this@see.sigblock> wrote in message
news:346sp3-uer.ln1@pluto.downsfam.net...
> Vincent Delporte wrote:
>
> > Hello
> >
> > I'm about to write a prototype for a business application, but since
> > this my first real web application, I'm looking for a good book or
> > article that sums up the different issues web developers will
> > encounter when coming from the world of dedicated applications (VB,
> > Delphi, etc.)
> >
> > I'm thinking of issues specific to web apps like the statelessness of
> > HTTP, dealing with the back button, etc.
> >
> > Any good resource? It'd be even better if they have examples in PHP,
> > but a language-agnostic resource is good enough.
> >
> > Thank you!
>
> Can I assume you come from the world of LAN apps, or Client/Server? If
so,
> I can share some experience, which I hope may be of use.
>
> Probably the most important thing is to identify the architectural
> differences between web and your past experiences and to embrace them
> thoroughly in your new designs.
>
> For instance, consider statelessness. My background in desktop and C/S
apps
> made this incomprehensible to me at first glance. How could anything
> possibly work with no memory of the last request? At first I began
> investigating sessions and schemes for maintaining state with the idea in
> mind of keeping my stateful mindset. Though I learned a lot, this did not
> give me a working system. At some point it dawned that statelessness must
> be embraced and worked into my entire mindset, at which point the code
> flowed and the systems worked.
>
> The same goes for the back button. You can't stop them from hitting it.
A
> desktop guy will attempt to prevent it by popping up a browser window with
> no toolbars. But all such schemes can be defeated because the reality of
> the web is that the user is in control of the client, so you have to
> embrace that fact in your design and enforce your needs in other ways.
>
> Same goes for input. You can't control what the user sends, they can send
> any kind of malicious code imaginable, so you have to code that assumption
> in.
>
> Anyway, that's my experince, hope it helps in some small way.
>
> And good luck! Come on in, the water's fine!
>
>
> --
> Kenneth Downs
> Secure Data Software, Inc.
> (Ken)nneth@(Sec)ure(Dat)a(.com)
Navigation:
[Reply to this message]
|