SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 37
  1. #1
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Are PHP apps fundamentally data driven?

    Just kicking off a discussion. Data driven programming - some links;

    http://www.faqs.org/docs/artu/ch09s01.html
    http://simon.incutio.com/archive/2003/12/05/dataDriven
    http://www.catalysis.org/publication...a-vs-behavior/

    Hypothesis - because PHP (as an Apache module) ditches memory between requests, implementing an effective Domain Model has too much overhead. Data driven programming is more suited to PHP where the typical "flow" on a request is DB > Query > Transform Data > Render to Browser. Data has to get to the final stage as quickly as possible, given no mechanism to store it in memory.

  2. #2
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Are PHP apps fundamentally data driven?
    Are they ? I guess so for the most part, yes IMHO.

    PHP doesn't have persistence as such as Java has I guess ? So we're kind of limited in that sense of how we can use PHP.

    And I'm not trying to start a flame war on this discussion either

  3. #3
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Anti topic actually : Would it be possible to combine some of the shared memory functions http://www.php.net/manual/en/ref.sem.php or http://www.php.net/manual/en/ref.shmop.php with serialize to create a persistance layer? Obviously you could not rely on that senario in many shared environments, but I would think it could at least be theoretically possible.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  4. #4
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by HarryF
    Hypothesis - because PHP (as an Apache module) ditches memory between requests, implementing an effective Domain Model has too much overhead. Data driven programming is more suited to PHP where the typical "flow" on a request is DB > Query > Transform Data > Render to Browser. Data has to get to the final stage as quickly as possible, given no mechanism to store it in memory.
    Hm...I have been thinking along similar lines recently regarding functional and declarative stuff. The following thoughts are random...

    You could say the same with a simple GUI client server app. In practice these apps. make heavy use of logic as stored procedures in the DB for the business invariants and so keep the GUI portion cleaner (except for validation). From their own point of view these apps. are highly data driven, but are only one style of GUI app among many.

    If data is going to be under the control of users/customers with little automation, then programs are not only data driven, but actually data blind. They just stuff things on the screen regardless of their underlying meaning. It is the users that do the processing, not the code.

    Data driven (not blind) apps. start to hurt as the problem gets larger. Even with SQL, as the data model gets larger it gets progressively harder to fix things that get mis-modelled. I think this helps to account for the popularity of OO amongst enterprise developers. If you do go down this avenue, definitely keep application data separate from the core data tables. The core data model should stand on it's own and everybody should know that changing it is changing the business model. With the application data/flags/states in their own tables you will get some extra joins, but it means that developers are much more able to refactor this part.

    If a data driven app can be understood by me at all, I can understand it completely. On the small scale I find writing SQL views/triggers (Postgres 7.3+/Sybase) is really quick. Not so easy to test though, so I tend to do this for my own small projects where maintanence is not an issue.

    I think OO is the nicest way to build machinery. Recently we had to do some complex web spidering work that involved a flexible and highly parallel two stage fetch and parse. Even the flow chart for this looked daunting (lot's of caching and retries). Our solution was to code roughly a class for each stage of the job control and another that assembled all of the pieces. The assemblies were a one to one declaration of the job flow relations on the different diagrams. In this way the app. structure became data and OO was used to hide everything that didn't make the construction expressive.

    If you are using an O/R mapping system, then your application can be either object or data driven. The data exists in the DB, the behaviour exists in source code and the two are joined before your app. even has a chance to debate the issue. In the absence of this, I am a big fan of the ActiveRecord pattern for a cheap and cheerful way to get a balanced app. out the door. It keeps the object model isomorphic with the data model, making the landscape easy to understand, but leaves a clear place to put behaviour.

    When talking to clients/businesses OO descriptions are far more meaningful than tabular descriptions. Saying you will add a row to the permissions table is just not as clear as saying that you will grant a person access to a resource. That objects follow the contours of the domain is one of the things that seems to make them robust to changes.

    All this is more feeling rather than anything I can back up logically.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  5. #5
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by sweatje
    Off Topic:

    Anti topic actually : Would it be possible to combine some of the shared memory functions http://www.php.net/manual/en/ref.sem.php or http://www.php.net/manual/en/ref.shmop.php with serialize to create a persistance layer? Obviously you could not rely on that senario in many shared environments, but I would think it could at least be theoretically possible.
    Sure is. It's called Prevayler. Please, please somebody take over the PHP version of this project. It is a perfect fit for PHP.

    yours,Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  6. #6
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    From http://www.faqs.org/docs/artu/ch09s01.html:
    When doing data-driven programming, one clearly distinguishes code from the data structures on which it acts, and designs both so that one can make changes to the logic of the program by editing not the code but the data structure.
    If I understand Raymond's text (and I think I do, but there is no guarantee ), then the 'data' in this context is the data which controls the flow of the application, not necessarily the business data in the database. I've been (privately) using the term 'configuration driven architecture' for a while now, along with the concern of 'separating application knowledge from business code'. I think these are less ambiguous, since they don't contain the word 'data', which is commonly interpreted as 'business data'.

    Data-driven programming is sometimes confused with object orientation, another style in which data organization is supposed to be central. There are at least two differences. One is that in data-driven programming, the data is not merely the state of some object, but actually defines the control flow of the program. Where the primary concern in OO is encapsulation, the primary concern in data-driven programming is writing as little fixed code as possible.
    Mr. Raymond makes it appear as if DDP and OO are mutually exclusive, but I've been working on my own application (architecture) for just over a year now, and it combines a configuration-driven architecture with the encapsulation provided by OOP. There's a basic example of how my architecture works in this thread.

    As for the question in the topic: I'm not entirely sure what you're asking... I believe most scriptlike applications can benefit from a data-driven design (data/configuration that controls the flow/behaviour of the application) since it will probably decrease the amount of code, and increase code flexibility and re-use. I've never bothered with a Domain Model or Domain Objects, because like you said, objects in PHP are too shortlived to have any real use in a true OOP sense (like giving a User object some behaviour). Another thing to keep in mind is that all data loses its meaning when it's parsed into the Document template, and any meaning it has within our applications only exists because we've created an architecture that requires and implies such meaning. The only place where your data needs to have a meaning is when it's being presented to a human. And it's generally not even data at that point anymore; it's content.

    It's late (almost 2 am). Am I making any sense here?

    Off Topic:

    Quote Originally Posted by HarryF
    Data driven programming is more suited to PHP where the typical "flow" on a request is DB > Query > Transform Data > Render to Browser.
    It might seem like nitpicking, but web applications don't render data content. That task may be handled by the client software that made the request, but this is no concern of the web application. Its job is to fetch the data required for the current request, convert it into content that matches the doctype of the outgoing Document, merge the two, and return the final Document. Many people seem to have the mental picture that their web apps render the content because their webbrowser is their primary means of viewing the output of their scripts (hence the abuse of the term 'View'). Understanding that this is not the case may help to get rid of the unfortunate use of MVC terminology in web applications, which is currently my main goal in life.

    Sorry for bothering you...

  7. #7
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    If a data driven app can be understood by me at all, I can understand it completely. On the small scale I find writing SQL views/triggers (Postgres 7.3+/Sybase) is really quick. Not so easy to test though, so I tend to do this for my own small projects where maintanence is not an issue.
    Or Oracle Packages. One reason I like to move more of the logic of an application there is skill sets...we have quite a few people with PL-SQL skills, but very few will HTML (funny...I bet this is reversed in most locations )

  8. #8
    SitePoint Addict mr tinkles's Avatar
    Join Date
    Jan 2003
    Posts
    262
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Are PHP apps fundamentally data driven?

    the PHP processor/engine/jobber, is an app/app server.

    client request...

    webserver...

    webserver pass to PHP, wait for response, pass back to client request...

    client webserver gets response, pass back to client...

    client sees.

    PHP, small part of the whole process.

  9. #9
    SitePoint Addict
    Join Date
    Aug 2002
    Location
    Ottawa, Ontario, Canada
    Posts
    214
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    If a data driven app can be understood by me at all, I can understand it completely. On the small scale I find writing SQL views/triggers (Postgres 7.3+/Sybase) is really quick. Not so easy to test though, so I tend to do this for my own small projects where maintanence is not an issue.
    In Oracle you can use utPLSQL to build test cases. Also, the IDE I use for PL/SQL development PL/SQL Developer will build an individual test case for a procedure/function, which can then be saved for re-running again later.

    I know that both Jason Sweat and myself do a lot of work in Oracle. As a matter of fact, these days, 100% of my db interaction at work is with Oracle. So I tend to move as much logic as possible into the database inside packages/procedures.

    I am actually writing a forum at work right now (tentatively being called fuseForum which I plan to release under an Open Source license of some sort - it uses the Fusebox framework), and it is interesting when dealing with some of the query classes to know that there is a "simple" single procedure call in Oracle, but when it comes time to write the MySQL versions of the same methods I will need to run multiple queries and embed a lot more logic in the query method in order to achieve the same results.

    Already we have in the neighbourhood of 65 public procedures in Oracle packages, and when I get around to writing the MySQL version, I am guessing the number of queries will jump to 100 at least for the same place we are now in development. And I have a strong suspicion that some of the tables will need to be denormalized a bit to take some pressure off a MySQL database.

    To sum up, in my book, for where I develop, logic in db = good

    Cheers,
    Keith.

  10. #10
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by HarryF
    I agree with Azmo. What Raymond describes has to do with configuration versus hard-coding. A painful example from my past was a manufacturing system that had hard coded the locations of the factories that the company had into various logic statements in the program.

    Code:
    If p = "A" OR p = "F" OR P = "M" THEN
    We spent 6 weeks adding "E." The major feature of the next generation of this system was to be data-driven. ALL such constants were moved out of the program into various files and databases.

    This system had an example where we went too far. I wrote a data-driven pricing system for the company which could represent very complicated deals and pricing situations in data. Previously, a person would review every invoice and adjust the prices based on various negotiated deals and terms. This was called the pre-billing edit. The purpose of my program was to remove the pre-billing edit and it did so. The problem was that sales was allowed to negotiate very complicated and oddball deals. As a result, sometimes it was very difficult for them to understand how to actually enter the data representing the deal into the computer. We had another data-driven system for bill of materials, called the requirements builder, which was notoriously difficult. The users all but washed their hands of it, and when new product categories had to be entered, very often a programmer would have to do it.

    The lesson of these two systems is no that data driven systems is bad. These real problems were complex. (The GOAL of the pricing system was to be complex and to make direct price comparison between us and our competitors impossible.)

    In our data-driven system, we had a rule that there could be no tests against constants in the code, ever. (well, sometimes zero and one are ok)

    One interesting consequence of this is that when we wanted to validate the length of a field that user was going to input, we would read the size of the field from the structure of the database table and compare against that. I miss this feature and plan on bring it to WACT some day.

    Its this data-driven tradition that makes me adopt the design rule that HTML and PHP shall not mix in my code.

    I have expanded this idea in recent years to remove all natural language strings from my code entirely.

    I don't see data driven and OO as being opposed.

    I don't see this article as having much to do with the first two. A model or data driven process versus a behavior or use case driven process?

    We used to have a saying early on in that manufacturing system, "Design the tables right and the code wlll write itself." Well, what happened is that our programs ended up mirroring the databases with CRUD capability. So for example, a Use case "Add a Product" might involve visiting twenty or so different input screens in six programs because there were twenty or so different tables involved across six subsystems. For some reason, the users considered this to be difficult to use. This is the fallacy of the naked objects philosophy. This is also why MDA is a dead end. Use case = user centered. data driven = programmer centered.

    We had a high powered catalysis consultant on site for this project in the later years. one of the specific benefits of catalysis is that it offers a conceptually clean way of modeling both behavior and state in your methodology. Catalysis is an underrated methodology.

    Quote Originally Posted by HarryF
    Hypothesis - because PHP (as an Apache module) ditches memory between requests, implementing an effective Domain Model has too much overhead.
    Who knows. Today's overhead is tommorrow's who cares?

    Quote Originally Posted by HarryF
    Data driven programming is more suited to PHP where the typical "flow" on a request is DB > Query > Transform Data > Render to Browser. Data has to get to the final stage as quickly as possible, given no mechanism to store it in memory.
    Think of this as document driven and perhaps it will make more sense. The "document" can be the data. document doesn't have to mean XML/SGML derivative.

    For example in WACT, the dataspace interface represents a document in "PHP variables" Format. PHP's associative arrays make a pretty flexible "document." In WACT, the database classes generate dataspaces. Templates/Views consume dataspaces. The controllers (actions) transform dataspaces.

    The advantage of a document driven architecture versus an OO architecture, is Loose coupling between components.

    Perhaps its the document driven style that fits well with PHP and web development.

    (Oh, the mainframe folks have been doing document driven for a long time. They call their documents messages and their software message oriented middleware.)

  11. #11
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It might seem like nitpicking, but web applications don't render (data) content.
    Good point - I'm usually more pedantic about defining layers.

    It's called Prevayler. Please, please somebody take over the PHP version of this project. It is a perfect fit for PHP.
    Would probably be alot of fun to do as well.

    As for the question in the topic: I'm not entirely sure what you're asking...
    Really I'm groping around for something here, without knowing what it is (could be just me).

    In the broadest sense, I often get the impression that no one really knows what PHP is good for. Everyone who's used it knows it does something well but I'm not sure if anyone can say why / when PHP makes a good choice. As the Creator puts it;

    PHP has never been just a scripting engine with some cool add-ons. PHP has always been the solution to the Web problem with even more bonus add-ons. And as I have said so many times, PHP is not about purity in CS principles or architecture, it is about solving the ugly web problem with an admittedly ugly, but extremely functional and convenient solution. If you are looking for purity you are in the wrong boat. Get out now before you get hit by a wet cat!
    Rasmus also claims responsibility for the LIMIT clause in MySQL (and now PostGreSQL). In a DB like Oracle, this is a painful subselect. Interestingly, I've seen things like limitQuery() (abstracting the SQL to provide LIMIT-like functionality on other databases) done in PHP database libraries (although perhaps I haven't looked hard enough).

    Being specific I'm wondering if being more focused on mechanisms to handle data (or configuration - not sure which I'm after), it's possible to define useful components for PHP.

    Taking my own example, PEAR::Calendar, what got me to write it was being unable to find a calendar class which was abstracted from both output (HTML) and / or data store (typically a MySQL table). PEAR::Calendar calculates calendar data structures (PHP arrays), wrapping them in objects which provide an API that's useful when generating a calendar in HTML (and XML type documents are generally rendered in a sequence), as with this example. It relies heavily on decorators to add functionality. There's some areas where it could be smarter (such as lazy evaluation of the data structure, as opposed to the current build() method) but, in general, think it "works" for PHP (and I think I got lucky with the design although you may disagree). I don't think PEAR::Calendar would be suitable in an environment where it persists in memory and may become the focus of a calendar application. For starters API to access the collection of calendar objects is too limited (although that could change) and preserving the integrity of a calendar data structure (e.g. days in a month) would likely be a problem.

    Along the same lines, where hierarchical (tree) data structures are concerned, I think it's possible to so something similar to PEAR::Calendar - organise the data structure in a manner where it can be handled within a single loop, so that it can easily be used when rendering HTML. That ones a little more complicated I think, as there a number of different ways people might want to access the tree - these forums for example - the breadcrumb navigation along the top requires a different structure to that which displays all the messages in a given forum.

    Think of this as document driven and perhaps it will make more sense. The "document" can be the data. document doesn't have to mean XML/SGML derivative.
    That may be exactly what I'm groping for. Perhaps the real question here is if we think in terms of "useful documents", can we design more useful components for PHP? My guess is there's a finite number of "documents" required for any PHP application.

  12. #12
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    It's called Prevayler. Please, please somebody take over the PHP version of this project. It is a perfect fit for PHP.
    Stuff like Prevayler scares me s***less. I think if we added Prevayler to the options available to PHP programmers, a lot of people would move to a programming style even more similar to Java, which would be a real shame. PHP's main strength IMO is that it is a language much more suited to the extremely simplistic environment of web applications. Personally, I'd like to keep it that way.

    Quote Originally Posted by HarryF
    In the broadest sense, I often get the impression that no one really knows what PHP is good for. Everyone who's used it knows it does something well but I'm not sure if anyone can say why / when PHP makes a good choice.
    IMO PHP is a great choice for writing simple remote function calls, which is what web applications really are; the client software extends its local Model by making a Request to a remote server when the user clicks on a link. The sense of an 'application' is created by pointing to related function calls in the returned Document.

    Off Topic:

    There's actually a lot more to it than this, but that would force us into a long discussion on the nature of web applications, which is not what this topic is about. Might be interesting to do though, because I haven't come across anything that analyzes what web applications really are.


    PHP in it's truest form (having one script file for each Action a user can Request) is the cleanest solution to dynamically generated content, but it has little or no code reuse. So we design architectures, libraries, and whatnot, to make the programmer's life easier and more productive. But no matter how complex our architectures get, we must always remember we're only writing groups of remote function calls, not applications in their normal sense.

    - - -

    I'm getting the impression that there are two interpretations of the term 'data-driven' being used in this topic. The first being the 'official' definition (as described in Eric Raymond's book), where the application's flow and actions are based on application data (or configuration). The second being related to the point of having a full Domain Model when all state is lost after each request. I think both are interesting enough to merit separate topics. Maybe we should try to find a way of distinguishing between the two, to avoid confusion...

  13. #13
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by HarryF
    Hypothesis - because PHP (as an Apache module) ditches memory between requests, implementing an effective Domain Model has too much overhead.
    I can see several issues that are involved here:


    The need for object references. Another problem which makes it harder to implement a Domain Model in PHP 4 is its abnormal handling of object references. This, of course, has been rectified in PHP 5.

    Programmer efficiency vs. program efficiency. A Domain Model is primarily a tool for making a complex application easier to extend and maintain. So it's about programmer efficiency. Since there are situations in which program performance is not an issue (in practice), a Domain Model should be useful in some situations. So general considerations about data-driven programming wouldn't invalidate the use of a Domain Model for all situations.

    Speed of session persistence vs. speed of permanent persistence. Java servlets store session infomation in memory (right?), so it should be more efficient than PHP session handling. But it's a difference of degree. As long as session storage can be faster than permanent storage, it may pay to keep objects in session. And if so, a PHP Domain Model could be as fast as, or faster than, any alternative.

    PHP vs. Web programming in general. If PHP apps don't usually implement a Domain Model, it may have more to do with the fact that Web apps in general tend to be simple than with the nature of PHP. (And, of course, there's the fact that many PHP programmers don't know a Domain Model from a fashion model and would rather be with the fashion model.)
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  14. #14
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Taoism
    To sum up, in my book, for where I develop, logic in db = good
    I came to data modelling before going on to OO. Although I have a fondness for writing data models, I have found that no model survives the first change request. It comes back to client/server only being good for apps. that are within the bounds of human control (read small). I am talking the data controlling the app. (constraints, triggers) not the raw tabular data here. It all comes down with a crash once you overstep that limit.

    I have been involved with two projects where this has happened. The first was a telephony system with a small, but simple flaw in the data model. I wish I had been more vocal about this at the time, but wasn't so confident then (I was exiting my own failed business). This flaw entangled the model and made it difficult to change. With the data model temporarily stuck fast the client code started getting workarounds grafted on at a rate of knots, further fixing the model in place. The price of change became so great that separate tables were being used to do calculations that were then inserted into the main model. Luckily the company collapsed before the system did.

    The other I came to later and was actually much smaller. We worked out a plan for fixing the model by building a virtual model from views, then moving to an object model, moving the triggers to the OO code and finally fixing the underlying data. To do this we would have had to get the data out of MySQL and into another DB. The time allowed did not justify it. That system was never deployed.

    Even expert data modellers take time to fight through an unencapsulated forest. I now think the OO bar is far lower than I first realised.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  15. #15
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Azmo
    IMO PHP is a great choice for writing simple remote function calls, which is what web applications really are; the client software extends its local Model by making a Request to a remote server when the user clicks on a link. The sense of an 'application' is created by pointing to related function calls in the returned Document.
    Any language is a good choice for writing simple remote function calls. In fact Tcl and SNMP are excellent choices. The problem is trivial.

    A web "application" whole is the sum of these network call parts, in the same way that a GUI app. is the sum of the event handlers. How these events interact and affect the underlying model is what defines the application and is where the real work is. What distinguishes PHP from Java is where PHP gets it's model from. Because each event is in a separate process, the necessary parts of the model must be reconstructed from shared memory or storage. The advanatage of Prevayler is that it can come from shared memory in a way that is transactionally safe.

    I have a lot of discussions with other developers, but the ones I relate to most easily are the Java developers. They seem to be involved in all the same problems that I run into day to day.

    Quote Originally Posted by Azmo
    Might be interesting to do though, because I haven't come across anything that analyzes what web applications really are.
    I'll punt . A parallel high latency network event driven application.

    Quote Originally Posted by Azmo
    ...is the cleanest solution to dynamically generated content, but it has little or no code reuse. So we design architectures, libraries, and whatnot, to make the programmer's life easier...
    Isn't this something of a contradiction .

    Quote Originally Posted by Azmo
    I'm getting the impression that there are two interpretations of the term 'data-driven' being used in this topic.
    I agree, although I don't think there is such a sharp dividing line. I tried to define "data blind" for shovelling out data that has no effect on program flow, but this stuff is often in the minority.

    I am a big fan of using configuration to set up underlying architecture. Being able to log onto different resources through a config file or to redefine the object model in XML are very programmer friendly (as Jeff points out). That stuff is architecture though, not part of the business/domain language.

    If you want to create a really flexible app. (it will try to go that way whether you fight it or not) you are involved in the job of language construction. This statement...
    PHP Code:
    $account->accrue($invoice->getTotal()); 
    ...uses words that are all business terms. Here the grammer is OO, but in a complex project you could use a rules grammer (Prolog?). This is the part that is missing from script driven apps. and ends up distributed in database driven apps.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  16. #16
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Stuff like Prevayler scares me s***less
    Be afraid - I'm just dying to take a shot In reality, probably not enough time.

    There's actually a lot more to it than this, but that would force us into a long discussion on the nature of web applications, which is not what this topic is about. Might be interesting to do though, because I haven't come across anything that analyzes what web applications really are.
    Fire away (perhaps a new thread).

    I'm getting the impression that there are two interpretations of the term 'data-driven' being used in this topic. The first being the 'official' definition (as described in Eric Raymond's book), where the application's flow and actions are based on application data (or configuration). The second being related to the point of having a full Domain Model when all state is lost after each request. I think both are interesting enough to merit separate topics. Maybe we should try to find a way of distinguishing between the two, to avoid confusion...
    Agreed. My vote for the latter case is to talk about "document driven", prompted by Selkirk (so perhaps this thead should have been called something like "Is PHP best suited for document driven design?") and leave "data driven" to Eric Raymond.

    So general considerations about data-driven document driven programming wouldn't invalidate the use of a Domain Model for all situations.
    Agreed. The question there is how to connect the two approaches effectively?

    Speed of session persistence vs. speed of permanent persistence.
    Think session persistence in PHP is not a significant problem (a files based approach may be an issue when you have alot of session files - believe most OS's get slower when you ask them to find a file in a directory containing a massive number of files) but that can be easily switched to a DB). Permanent persistence is another story and I think most people who've tried it with PHP have used a DB as the store (e.g. eZ publish) then you run into issues of with the number of queries required, as data volumes and traffic get big. There is an argument for phpPrevayler... or alternatively you say use some other technology when your app needs this.

    Perhaps a useful example for permanent persistance would be an "Purchase Order" from an online shop. First a customer adds items. Next they add billing / shipping info and complete their part of the order. Next someone from the shop needs to approve the order and from there, there might be some mechanism for shipper to update the order with deliver status.

    Off Topic:

    Some of what lastcraft and sweatj describe smells like where I work. End users have alot of power over the data. Oracle. 2-tier GUI. Only I know HTML...

  17. #17
    SitePoint Member
    Join Date
    Feb 2004
    Location
    sonora, ca USA
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    If a data driven app can be understood by me at all, I can understand it completely. On the small scale I find writing SQL views/triggers (Postgres 7.3+/Sybase) is really quick. Not so easy to test though, so I tend to do this for my own small projects where maintanence is not an issue.
    I have a fair amount of my business logic in Postgresql functions/triggers/views. I haven't gotten to the point of retroactively writing test cases for this logic but I intended to write tests as modifications are made and time allows using Simple Test and a live (non-mocked) database connection. What difficulties do you find testing database logic, aside from the complications introduced by testing against a real database connection?

    culley

  18. #18
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by culley
    What difficulties do you find testing database logic, aside from the complications introduced by testing against a real database connection?
    I wrote a little Perl unit tester for Postgres that would snapshot a table and then check for differences after the operation. I could in affect assert that a new row had been added. Easy I thought, but it was the test data entry that turned out to be tedious. If you can get the sample data in without excessive typing then you have advanced beyond me.

    I am moving to the idea that operations on a system should form a mathematical "group". If you have an add, you should have a delete and an existence check and so on. Otherwise you have to set up tests in another paradigm. An example of this is when building DB infrastructure. You create an object (OO), but assert it's presence by checking database tables (Relational). Really you want to test in the OO domain, but you probably haven't written that bit yet.

    Mock objects actually get in the way here (ironically), because without the database an object create() call won't match up with the exists() call because nothing was actually created. They make up for the paradigm translation by being easy to write and fast to run, so I guess I am still winning.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  19. #19
    SitePoint Member
    Join Date
    Feb 2004
    Location
    sonora, ca USA
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Easy I thought, but it was the test data entry that turned out to be tedious. If you can get the sample data in without excessive typing then you have advanced beyond me.
    You are talking about big sql operations-- I see your point here. Testing giant update statements is potentially very ugly. I don't see how you could avoid the same problem when testing OO code and a Mock database...

    Even with OO Code and a Mock database, I am finding test data generation is the most tedious part of testing. I have been building $before and $after arrays. $before data is used for the mock select statements that initiates the data in the object and $before data is used in the testing assert statements for the getters. $after data is used to test the setters and for testing the mock update statements. For testing non bulk database operations (for instance a trigger that forces a column to upper case) the test data generation would be no more tedious.

    culley

  20. #20
    SitePoint Addict
    Join Date
    Aug 2002
    Location
    Ottawa, Ontario, Canada
    Posts
    214
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I came to data modelling before going on to OO. Although I have a fondness for writing data models, I have found that no model survives the first change request. It comes back to client/server only being good for apps. that are within the bounds of human control (read small). I am talking the data controlling the app. (constraints, triggers) not the raw tabular data here. It all comes down with a crash once you overstep that limit.
    I guess I should clarify and say that I don't attempt to dump all the logic into the DB, just where it "makes sense" (why do I get the feeling a sentiment like that opens a whole can of worms). For example, for processing a login, there are many steps in the process:

    1) Is there a matching username in the db?
    2) Is the account effective date earlier than today (active)?
    3) Is the account expired?
    4) Is account locked because of bad logins?
    5) Has 10 minutes passed if the account is locked?
    6) Does the password match the hash in the db?
    7) If not increment the bad logins counter (lock account for 10 mins after #3)
    8) etc...(there is more, but the above should suffice)

    I wrap all that logic into one procedure call in Oracle and raise an application error from Oracle where appropriate if the step requires it. Where as in MySQL there will be multiple queries and logic in PHP to handle getting a result back. It is just much cleaner to move all that into a single procedure call if possible. That is what I meant by logic in db = good. I don't go heavy on triggers (except for some bulk loading to get around Oracle 8i's lack of an UPSERT feature). I do use a few CASCADE ON DELETE constraints to save some time.

    For other parts of the application, I do the work and make decisions directly in PHP (i.e. pull data back and process in the scipt and not the db).

    Cheers,
    Keith.

  21. #21
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by HarryF
    Permanent persistence


    Microsoft has a good article on Managing state in web applications

    What PHP lacks is the Application level state.

    Use the Application object when:
    • You have to manage application-wide state that is not specific to any particular user or session.
    • The state does not have to survive the life of the process the application is running in.
    • The state is sensitive and cannot be passed across the network.
    • You have substantial amounts of read-only state that you can load into the Application object at the start of application execution. An alternative solution might be to cache the data; for more information, see "Caching State" later in this chapter.

    Before deciding to use the Application object, consider the following points:
    • The Application object is a dictionary-based, in-memory storage mechanism, meaning that it is fast, but storing large amounts of data affects the performance of your server.
    • Because the state is stored on the server, the Application object offers higher levels of security than the client-based state mechanisms such as cookies, hidden form fields, and query strings; however, because all application code can access the Application object, it does not provide as secure a solution as the Session object.
    • You must synchronize access to Application state data, because other threads may be accessing the state at the same time. This means the Application object is best for read-only state.
    • Unlike the Session object, you cannot specify a timeout value after which the Application object state expires. Data in the Application object is retained until you remove it or until the application terminates.

  22. #22
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    What PHP lacks is the Application level state.
    To some extent, that is primarily what I end up using my PHP DataCache project for...persistant application state. Some argument could be made for storing configuration state in a DB as well...

  23. #23
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The important aspects of the application level state (read as Application Server level) are that it is memory based, cross-request, temporary, and fast. There is no reliable standard for this in PHP.

    The shared memory extensions are not in the standard distribution. That rules out their use for some purposes. Plus I have read that they are buggy. (?)

    Also, doesn't prevelayer have some sort of disk journaling or something?

    An interesting option is mysql's in memory HEAP tables. John Lim's Benchmarks on HEAP tables don't show them as being much faster over the network. However, it would be interesting to test them with MySQL running on the same server as PHP.

    Presumably in this hypothetical architecture, you might use multiple copies of MySQL. A local copy on each web server running running HEAP tables, with a global DB server on another machine with standard tables for "permanent persistence." The global DB server need not be MySQL.

    HEAP tables might be a good backing store for your DataCache classes, Jason.

    What would be a good thing to stick in there? Perhaps that pesky Phrame configuration file?

  24. #24
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ...slower when you ask them to find a file in a directory containing a massive number of files...
    I for one, can verify that this is in fact, very true But mostly the problem is with Windows* rather than with *nix

    I've seen Windows take a full 30 seconds to open a folder which is only 4 down from a root, and my box isn't all that old nor slow processor either.

  25. #25
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    HEAP tables might be a good backing store for your DataCache classes, Jason.
    Interesting idea, might actually provide a motivation to implement the MySQL DAO

    Quote Originally Posted by Selkirk
    What would be a good thing to stick in there? Perhaps that pesky Phrame configuration file?
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •