SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 67
  1. #26
    What? Maelstrom's Avatar
    Join Date
    Oct 2001
    Location
    Whistler BC originally from Guelph Ontario
    Posts
    2,175
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice artical and thank you. ...The only thing I was having a problem grasping was the reason to use this type of thing

    Loop::run(new QueryIterator($result),new ResultDisplay);

    I am starting to get most of the features discussed in this 'article'. I have been able to work through the code provided by Voo and work out most of my dilemas with advanced oop ...

    For a basic design theory. If we were creating a artical manager (one small piece of a CMS) you would subdivide classes up into

    db //class to handle connections with db
    queryResult ///class to handle the querying and information based on those queries
    queryIterator //class to handle the iteration of the rows fetched by the queryResult
    Loop::run //class to display (iterate) the query using the template class
    ResultDisplay //template class setting various section of the iteration 'DISPLAY' settings

    Obviously this will handle any query given it and display that query according to the ResultDisplay I define.

    Loop::run(
    new QueryIterator($db->query("select * from blah blah")),
    new resultDisplay
    )

    Do I have this so far This works great for things like displaying lists of sections AND/OR lists of articles and the article itself.

    For a templating system to seperate your content from the template (keeping it in a DB) I have something like this in mind

    db //use above class to connect to correct table containing the templates
    QueryResult //reuse this class to fetch result #ID for templates and content

    fetchTemplate //This class fetches the db stored templates from the result ID
    createTemplate //uses information 'fetched' to create the template. This is similar to the manipulator in Voos class's

    fetchContent //class to retrieve 'content' or articles from the database

    Loop::Template //superclass to use template information to 'place' the templates in the right spot


    Loop::Template(
    new createTemplate(new fetchTemplate),
    new fetchContent($result2)
    )

    So what I have tried to do here is seperate each interface in to multiple areas

    1 - db control - open close, and query results
    2 - template display - using db control fetches and displays template
    3 - content display - using db control and fetches content based on page info
    4 - Loop::template - uses information from template and content to fully create a page.

    Just wanted to run this by you guys and see if this make logical sense or if I am just blowing wind. This is my first attempt at layering my oop in this manner.

    Thanx for any critism
    Maelstrom Personal - Apparition Visions
    Development - PhP || Mysql || Zend || Devshed
    Unix - FreeBSD || FreeBsdForums || Man Pages
    They made me a sitepoint Mentor - Feel free to PM me or Email me and I will see if I can help.

  2. #27
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Do I have this so far This works great for things like displaying lists of sections AND/OR lists of articles and the article itself.
    Yup, you've got it completely!

    <shameless self-plug>
    If you really want to try out this kind of programming, but don't want to do all the necessary work to create your basic classes (databases, query results, iterators, and so on), you might want to look here: http://www.sunlight.tmfweb.nl/eclipse/
    </shameless self-plug>

    Now, about those templates. I can see how you made your design. You have a template, and you have contents for this template. So, logically, you start with classes Template and Content. But what's next? You can either make the template responsible for showing itself in combination with the content ('$template->show($content)'), or you use an 'outside' mechanism, like a controller: '$controller->show($template, $content)'. It seems you went for this design. I don't know which one is better; it depends on the complexity of both the template and the content classes.

    When I write code, I always look at how it reads. This may sound silly, but when I examine any particular piece of code, I always want to be able to see immediately what job it has, and not necessarily how it does that. Code like 'Loop::run($iterator, $manipulator)' is (for me) very simple to understand. I can see clearly what it is meant to do. If I want to know exactly how it does its job, I'll have to dig a little deeper, which makes sense to me. This is not something I try to achieve in the highest level of my programs; I aim for that in all levels. Naturally, the higher levels are more abstract than the lower ones, but that doesn't mean they should be less readable.

    Vincent

  3. #28
    What? Maelstrom's Avatar
    Join Date
    Oct 2001
    Location
    Whistler BC originally from Guelph Ontario
    Posts
    2,175
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well I did borrow the code you posted here and inferred the remainder. Or at least the pieces needed by me Playing with it and adjusting it I have been able to create other iterators. Interesting set of classes and objects you have. Thank you for the time and effort you put into your posts regarding this issue. I know you have helped me tenfold grasp all of the aspects explained above.
    Maelstrom Personal - Apparition Visions
    Development - PhP || Mysql || Zend || Devshed
    Unix - FreeBSD || FreeBsdForums || Man Pages
    They made me a sitepoint Mentor - Feel free to PM me or Email me and I will see if I can help.

  4. #29
    SitePoint Zealot Alarion's Avatar
    Join Date
    May 2001
    Location
    Virginia
    Posts
    126
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    wow Voostind

    really.. wow. Maybe I should have gone to college after all.

    Currently, I have used basic OOP principles (much like PEAR uses) for my one OO project (Datalib) which just happens to be YADAC (Yet another database abstraction class). I did sperate the connections and results/recordsets into seperate objects, but I definately didn't go so far as using Object Composition

    Anyhow, I just wanted to say Thank You for taking the time to write those lengthy posts! Definately something to keep in mind whilst devloping future software!
    -=Alarion=-
    Protollix - Linux hosting from $3.95/m

  5. #30
    SitePoint Enthusiast Jujubee's Avatar
    Join Date
    Mar 2001
    Location
    Canada
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Wow. That is some great explaining.

    voostind, you should point the Sitepoint people to this thread, you 2 posts would make a great article for Sitepoint. If nothing else, I'm sure it will get a nice discussion going.

  6. #31
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    On DrL's point about OO performance back there, have a shot in the dark theory, based on my experiences with error reporting from classes.

    Basically, could it be the case that instantiate a class comes with a flat overhead cost in time, something along the lines of;

    Code:
    Flat overhead = Time to instantiate class + time to define properties + time to run Constructor method
    Then to use one of the methods within the class, you add to that an overhead for "declaring" and using that single method.

    Where as for functions you've got

    Code:
    Flat Overhead = time to declare each function
    Then you've got another overhead every time you use one of the functions.

    So basically classes pay off when you're dealing with alot of functions, i.e.

    You've got an include file with 10,000 functions in it (extreme I know but for the sake of argument) vs. a class with 10,000 methods.

    For the functions approach, each one must be declared, which makes a massive overhead.

    For the class, the methods only add an overhead when they are used.

    Anyway - a ballpark theory.

  7. #32
    SitePoint Guru Majglow's Avatar
    Join Date
    Aug 1999
    Location
    B-Town
    Posts
    645
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok... regarding performance.

    In the real world of programming a script to run on a server.... not just theory. How much would coding using OOP hurt efficiency.

    I'm quite the OOP guy, but that's mostly with C++ and other languages like that where OOP is a significant part of it. I don't know how good it really is with PHP.

    If I'm making a script that I am hoping to be able to sale later on, when it is complete with all features, debuged, etc... would having used OOP hurt it's over all performance on big sites?

    Can anybody give speed-up factors of using Procedural as oposed to OOP?

    Thanks,
    -cARL

    Edit:

    I swear I'm not reposting a question that was posted before in the tread, what I really want to know is if this slow down is acceptible for a "commercial" product?
    Last edited by Majglow; May 29, 2002 at 23:47.
    Ohai!

  8. #33
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't think it's possible to give raw numbers on speed differences between PP and OOP. There are too many factors that must be taken into account. Sure, you can run a test that calls some code as a function and a class-method 1000 times each, but that makes little sense.

    After years of studying on and experimenting with object-oriented programming, I can say the following in favour of it, compared to procedural programming:
    - I need much less (lines of) code
    - The software is easier to understand
    - The software is easier to maintain

    In that light, what do I care if generating an HTML page takes 0.06 seconds instead of 0.04 seconds? That problem can easily be solved by buying hardware. And because of the time (and thus the money) I'm saving, there's plenty of room for that.

    I'm not saying that buying hardware is always a valid solution to overcome slow code! When you implement a sorting algorithm in O(n^2) while it can be done in O(n log n), you can throw as much hardware at it as possible to make it faster, but it will remain crap.

    On the other hand, if you are using good algorithms and good OOP techniques (design patterns and such) and find little room for improvement while the software still runs (too) slow, than buying hardware is a perfectly good solution. It's much cheaper.

    Vincent

  9. #34
    Making a better wheel silver trophy DR_LaRRY_PEpPeR's Avatar
    Join Date
    Jul 2001
    Location
    Missouri
    Posts
    3,428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ehh, some quotes from Top 21 PHP Programming Mistakes; Overusing OO:

    The OO paradigm is a wonderful concept. It has numerous benefits, the most notable being the ability to reuse code easily. However, as we've all come to understand: 'PHP is not an OO language'.

    While PHP does offer adequate object oriented support, it is neither efficient nor wise to use its object oriented features when you can make use of other methods to achieve the same result. The reason for this is that PHP's OO support is not full blown.

    ...

    Nor is the code behind PHP's OO support very efficient or fine tuned. This means that when you use the OO paradigm with PHP, you may in fact be slowing down the execution time of your programs considerably.

    • Note: Generally speaking, an application that uses OO support will be slower just as using eval() will be slower than normal code. To amply show places where OO support gets somewhat ugly, I'd have to use advanced PHP features and concepts, some of which have not even been documented yet.


    ...

    If you are coming to PHP from a language such as Java or C++ where you can't really create complex programs without using object oriented features, bypassing PHP's OO support may be difficult. Let me assure you, however, that powerful applications can be written without the use of any OO concepts and methodologies (PHP was written in C, which has no OO support).

    ...

    Let me just clarify something. I'm not advocating that you abandon PHP's object oriented features entirely. Rather, I'm just trying to warn you not to use PHP like it was Java or C++ where one would freely use OO.

    Carefully balance the benefits with the drawbacks before you decide to use an object oriented approach with PHP.

  10. #35
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Although the author is right of course - OO in PHP is slower than PP - I would also like to say this:

    ...a language such as Java or C++ where you can't really create complex programs without using object oriented features...
    The fact that the author writes this, says to me he doesn't really know what he's talking about, at least when it concerns OOP.

    Let me assure you, however, that powerful applications can be written without the use of any OO concepts and methodologies (PHP was written in C, which has no OO support).
    As does this. While C doesn't have OO-support, it's perfectly possible to write object-oriented programs in it, using those 'concepts and methodologies' he claims can't be used.

    Don't get me wrong, I do think PHP's OO implementation is slow, but I also get very pissed when someone who doesn't know anything about it starts saying bad things about it. Of all people who claim they are writing software the OO-way, only about 5% of them really know what they are doing. Of those 5%, maybe 0.0001% is using PHP. I haven't yet seen ANY application written in PHP that uses OO 'the right way', and believe me, I examined a lot of packages, like PEAR, BinaryCloud, Javuh and so on. I'm not talking about WHAT they do - as they work fine in general - I'm talking about HOW they do it.

    If you really want to know about OOP, you'll have to search hard to find someone who can tell you about it, and the chance of that person also knowing PHP is very, very slim. (Of course, I am the noted exception ). Before everybody starts screaming: this is the same for Java- and/or C++ programmers. Very few programmers actually know what they are doing in those languages. OO is new and difficult, and it's easy to write large, inefficient programs with it, and that is what happens a lot.

    As I said before: OO-code in PHP is slower than PP-code. But because the codebase gets so much smaller and simpler (if done right, which almost never happens), that almost entirely makes up for the lack of speed. And it certainly will in PHP5.

    I am open to let someone convince me that I shouldn't use OOP in PHP, but the person who achieves that will have to qualify first:
    - Knowledge of real OO-languages like Smalltalk and in a lesser extend Java and C++ is a requirement.
    - Knowlegde of various OO-techniques and concepts (Design Patterns, Refactoring) is a requirement as well.
    - Some knowledge of PHP could come in handy.
    - A degree in Computer Science is a must.
    - A specialization in Software Technology is a must as well.

    Now, if they could find a couple of such persons who claim that OOP in PHP is a bad idea, supported by a list of valid reasons, I might just consider abandoning OOP in PHP...

    Vincent

  11. #36
    FreeBSD The Power to Serve silver trophy pippo's Avatar
    Join Date
    Jul 2001
    Location
    Italy
    Posts
    4,514
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Vincent and others,

    this is a very interesting thread that I printed it ( 26 pages actually ).

    I hope that in the future the PHP core developers will not reinvent the "wheels" so that we will have to modify the scripts we wrote using classes.

    An example could be:
    PHP Code:
    class pippo
    {
    var 
    $pluto;
    etc
    }
    $cartoon = new pippo;
    print 
    $cartoon->pluto
    Well the day that php people will introduce the way to render private / public a properties...will they use public as default ?!? ( I do not remember what C++ use )

    PHP Code:
    class pippo
    {
    // private: if private is the default...
    var $pluto;
    etc
    }
    $cartoon = new pippo;
    print 
    $cartoon->pluto//...this will not work 
    If in that case I had used a method ( a function ) to read that value, the problem will never exist.

    This is a poor example from my poor experience of how a bad use of classes could make problem in the future.

    I think that the more experienced people like you could help us to design at the present time a good class without be worried or reducing the panic of future php upgrades.



    ps
    I'm sorry but I hope that you will understand my very bad english...
    Last edited by pippo; Jun 4, 2002 at 01:33.
    Mr Andrea
    Former Hosting Team Advisor
    Former Advisor of '03

  12. #37
    SitePoint Member
    Join Date
    May 2002
    Location
    Ljubljana, Slovenia
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    gave up

    I've also tried to do OOP but gave up. Why?

    1.) the processes that code is trying to do is somehow hidden so when I look at a OOP code I can't quickly recognize what it is trying to do.

    2.) There are a lot of articles that show you how to write code in OOP. But I've seen none (which was clear) that shows you how to think OOP. Where are object limits? What can on object be? How to create an object that is similar to the real world objects? !!!!!!!!

    3.) I guess you have to spend more time planning when doing OOP. But if I planned it wrong? Is there any sense then? voostind mentioned: You can code in OOP but not realy making it OO. His post was VERY long.

    4.) With OOP object are not realy reusable. Well, they are but when you are trying to use an object that was programmed by someone else you must spend a lot of time learning what he was trying to do. But I guess this is because I don't realy understand OOP.

    Well, no I'm going offline to read voostind posts and try to learn something.

  13. #38
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by voostind

    On the other hand, if you are using good algorithms and good OOP techniques (design patterns and such) and find little room for improvement while the software still runs (too) slow, than buying hardware is a perfectly good solution. It's much cheaper.
    can you offer any guidelines/resources that describe how to create good algorithms and good OOP and maybe even some explanations of various OOP concepts, Design Patterns, Refactoring, etc?
    Last edited by shoebox; Dec 5, 2002 at 03:45.

  14. #39
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay:

    Cormen, Leiserson and Rivest, Introduction to Algorithms
    Gamma, Helm, Johnson and Vlissides, Design Patterns - Elements of Reusable Object-Oriented Software.
    Fowler, Refactoring - Improving the Design of Existing Code.

    Try these for starters; they are available at your local bookstore

    Vincent

  15. #40
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Also, for a great primer in OOP, try Thinking in Java (http://www.mindview.net/Books) - free online.

    1.) the processes that code is trying to do is somehow hidden so when I look at a OOP code I can't quickly recognize what it is trying to do.
    I've found OOP to be one of those wierd topics that is extremely hard to convery, at a fundamental level. The best approach is to look at alot of OO code and just keep exposing yourself to it. Eventually it will click and you probably won't ever want to go back.

    These days I find OO code easier to read than a procedural equivalent.

    2.) There are a lot of articles that show you how to write code in OOP. But I've seen none (which was clear) that shows you how to think OOP. Where are object limits? What can on object be? How to create an object that is similar to the real world objects? !!!!!!!!
    I think the best approach is to make sure you have examples which relate to things you already know in programming. If PHP is your thing, demand examples that relate to the web (as opposed to cars for example). Kevin Yanks paged result set is a great example of how it should be.

    The more you code with OOP, the more obvious in becomes what an object should be. A common problem for PHP coders is writing so-called "god classes" - classes which do more than perhaps they should. Say you have an authentication class, which checks user names and passwords, and incorporates starting PHP sessions and fetching data from MySQL. That may be fine for the current problem. But what when the next project uses PostgreSQL and also requires use of sessions for, say, a shopping cart.

    You now first need to re-write the class for PostgreSQL and then have to overcome the problems of potential conflicts between what the shopping cart is doing with sessions and what the authentication is doing with sessions.

    It would be easier to have three classes, one for sessions, one for authentication and one for database access - these now become independent problems to be tackled independently, and can be nicely re-used by other classes.

    3.) I guess you have to spend more time planning when doing OOP. But if I planned it wrong? Is there any sense then? voostind mentioned: You can code in OOP but not realy making it OO. His post was VERY long.
    I'm not sure that's true. I think I'm right in saying that the extreme programming methodology begins with the idea of "do some code first to build a prototype, then think hard once you've got there".

    In general, I think what's most important is learning how to construct good APIs (the method by which you provide access to the code in your class). If the API is sound, behind it you can radically alter the code without effecting any other classes.

    4.) With OOP object are not realy reusable. Well, they are but when you are trying to use an object that was programmed by someone else you must spend a lot of time learning what he was trying to do. But I guess this is because I don't realy understand OOP.
    Kind of covered this already. When using someone elses code, for example, they've hopefully documented it a userful manner. Once you get used to reading API documentation, you'll see it's pretty similar to the PHP manual, for example. Take a look at Vincent's own API documentation for Eclipse - a very good example of how things should be.

  16. #41
    SitePoint Guru
    Join Date
    Feb 2002
    Posts
    625
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not sure that's true. I think I'm right in saying that the extreme programming methodology begins with the idea of "do some code first to build a prototype, then think hard once you've got there".
    You thought wrong XP is for sure not what you think it is.

    Read this Extreme Programming: A gentle Introduction

  17. #42
    SitePoint Enthusiast Remy's Avatar
    Join Date
    Oct 2002
    Location
    Amsterdam
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I get the thinking of OOP (and N-Tier) development (I think ), but I got one problem with OOP: How to store the data.

    OOP is about thinking in objects. I have this on paper (please correct me if this is wrong or could be better):

    Article
    -------
    +Subject
    +Body
    +Date
    +PostedBy
    Get()\Set() methods
    Send()

    Memo extends Article
    --------------------
    +SendTo
    +SendCopyTo
    Get()\Set() methods
    Send()

    News extends Article
    ----------------------
    +Source
    Get()\Set() methods
    Send()

    How do I put this in a database?
    Should I take one table and set the field not needed for the current record to NULL (Takes a lot of useless space a think)? Can you give some hints how to store this the correct way in a RDBMS?
    Last edited by Remy; Dec 5, 2002 at 09:29.

  18. #43
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    (Remembering what I read from Martin Fowler's Patterns of Enterprise Applications ):

    There are three methods to map class inheritance to database tables:

    • Single Table Inheritance
      You'd have one table 'articles' which holds both memos and news items. In that table you have a field which holds a typecode for the class, something like a field called 'type' with possible values 'news' and 'memo'
    • Concrete Table Inheritance
      You have one table for each concrete subclass, i.e. two tables 'news' and 'memos'.
    • Class Table Inheritance
      You have one table for each class in the class hierarchy, 'articles', 'news', 'memos'. Each table for the subclasses ('news' and 'memos') have a field which relates them to the parent table ('articles'), something like articleID.


    I think in your situation, using Single or Class Table Inheritance would be a bit of overkill. Using one table for each subclass, news and memos, would probably be the best solution.

  19. #44
    SitePoint Enthusiast Remy's Avatar
    Join Date
    Oct 2002
    Location
    Amsterdam
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Captain Proton, thank you for your answer .

    I'm going for Class Table Inheritance, because I think it fits more to the thinking of classes and is more flexibel for future changes. The only thing that was holding me back from OOP was the datastorage. I have the feeling that OOP and RDBMS (normalization) doesn't mix well, but your anwser changed that. Not completely, but enough to start changing my projects to OOP.

    Voostind, a read a lot of articles about OOP but your explanation is clear, complete and better than what a read before. Thank you for your time to write this. It helped me a lot . (Don't get why this is not already made into article on sitepoint)

  20. #45
    Wanna-be Apple nut silver trophy M. Johansson's Avatar
    Join Date
    Sep 2000
    Location
    Halmstad, Sweden
    Posts
    7,400
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by Remy
    I'm going for Class Table Inheritance, because I think it fits more to the thinking of classes and is more flexibel for future changes. The only thing that was holding me back from OOP was the datastorage. I have the feeling that OOP and RDBMS (normalization) doesn't mix well, but your anwser changed that. Not completely, but enough to start changing my projects to OOP.
    I have a solution suggestion for the datastorage thingy.

    Essentially, have a property in your class called ID or DBID, or something like that. Then, have two methods called DBLoad() and DBSave(). The methods use the ID property to save/load data from the database based on the ID property of the object, which correspons to a index key column in the DBMS.
    Mattias Johansson
    Short, Swedish, Web Developer

    Buttons and Dog Tags with your custom design:
    FatStatement.com

  21. #46
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    131
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You could also serialize the objects by using WDDX (outputs a XML document) and store that in the DB (with a unique object ID as Primary Key)
    include_once('./sig.inc.php');

  22. #47
    Wanna-be Apple nut silver trophy M. Johansson's Avatar
    Join Date
    Sep 2000
    Location
    Halmstad, Sweden
    Posts
    7,400
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by KillaByte
    You could also serialize the objects by using WDDX (outputs a XML document) and store that in the DB (with a unique object ID as Primary Key)
    Smarty-pants!
    Mattias Johansson
    Short, Swedish, Web Developer

    Buttons and Dog Tags with your custom design:
    FatStatement.com

  23. #48
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So you have a record in some table, retrieve that to store it in a PHP object, and then use WDDX and overhyped XML to store that same record back in that same database?

    Right!

    Vincent

  24. #49
    Wanna-be Apple nut silver trophy M. Johansson's Avatar
    Join Date
    Sep 2000
    Location
    Halmstad, Sweden
    Posts
    7,400
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by voostind
    So you have a record in some table, retrieve that to store it in a PHP object, and then use WDDX and overhyped XML to store that same record back in that same database?

    Right!

    Vincent
    Yes? I don't see the problem with this.
    Mattias Johansson
    Short, Swedish, Web Developer

    Buttons and Dog Tags with your custom design:
    FatStatement.com

  25. #50
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes? I don't see the problem with this.
    You don't? Or are you kidding?

    Method 1:
    - Connect to the database
    - Execute a standard selection query
    - Retrieve a record, store it in an object
    - Use the object in code

    Method 2:
    - Connect to the database
    - Execute a selection to get the XML record
    - Retrieve the record
    - Parse the XML (yuk!)
    - Store the record in an object
    - Use the object in code

    Which do you prefer?

    Note that method 2 isn't even correct, because you should still execute the original query as well to make sure the duplicated XML record isn't invalid.

    Vincent


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
  •