SitePoint Sponsor

User Tag List

Page 9 of 11 FirstFirst ... 567891011 LastLast
Results 201 to 225 of 274
  1. #201
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    You seem to be saying that the rules of MVC require that the view 'pulls' data from the model whereas the use of XSL stylesheets requires that the data be 'pushed' via an XML document. Does this mean that it is impossible to use XSL stylesheets in the MVC design pattern?
    No, i think i got the boundary wrong in the last post. I think the concept of pull is central to traditional MVC. I think the code that does the pulling from the model marks the boundary between the view and the model. If this code is in your controller, it is a breakdown of the separation between the controller and the view.

    Just as I think that View != Template, i guess View != XSL. Those helper classes look important in both styles.

    Let me phrase this in terms of a thought experiment:

    Take an application written in your architecture. Now, what would have to change in your program to use a template based approach instead of an XSL approach?

    If you have really implemented MVC, then nothing in your controller layer should change. Only your view layer should change. The code you have to change to accomplish this switch belongs in your view layer. To return to an earlier theme, the view layer should encapsulate (or hide) an implementation detail such as templates versus transformation.

    Now pretend that there was some viable desktop option for PHP and that you were going to convert your application into a desktop GUI. Here you are changing both the method of input and of output. Your view and your controller will certainly need changes. Additionally, your application model will probably be different. The part of your application that didn't need to be changed to accomplish change should be your domain model.

    The degree to which you have acheived a separation of concerns is the degree to which imaginary changes such as these are limited to a single unit of encapsulation (function, object, file, package*).

    * package = a collection of other units of encapsulation (in the UML sense). you might call it a layer.

  2. #202
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Doesn't traditional MVC use the Observer pattern where the model is "Subject" and the view is the "Observer"? With the Observer design pattern, you should be able to use either push or pull methods. I don't think MVC specifies one or the other.

    JT

  3. #203
    SitePoint Enthusiast MickoZ's Avatar
    Join Date
    Jul 2004
    Location
    Canada, Qc
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Hi...



    I think this is why I treat them as synonymous. I'm going to define a few terms for the purpose of this thread only...

    I build a "package" of PHP code. Now anyone can access any bit of that package, but I am going to assume responsible developers here. Let's say I have written a tutorial and a few docs on how you are supposed to use the package and this is thus the "published" interface.

    Now I go away on holiday for a few weeks.

    Without looking at the source code, how do I know which parts of my published package have become dependencies and which parts haven't? Not just now, but in the future too. To me it feels like publishing an interface and then including it in a project is equivalent to declaring a dependency.

    yours, Marcus
    I don't know, trying to make thing simple and seeing it simplely.

    Visibility is one thing and dependancy is another thing.

    Visibility: can you see it?
    Dependancy: are you dependant of it?

    You can see/have access to 1000 girls, but be dependant of only 1 or 2 or 3 ...

    When you use a String object in Java let's say, you have visibility at all its Method, but you are not dependant of all of them in a particular place.

    I don't think we should interpret word like that, but rather see why they say visibility? what is visibility?

    Visibility: The fact, state, or degree of being visible.
    Dependent: Relying on or requiring the aid of another for support

    I have just give slight definition. But the word clearly express two different things. There might be a correlation with both concept in the application of OOP, however I am sure it will never be 100%. Don't mix up thing that always happen with what thing are... it is a common [pragmatic?] mistake people tend to do in life (I'm being very general there!)

    That is also the reason other term (encapsulation, etc.) are being misunderstood... people use their "usual" application to define them or a "supposition" rather than use its real definition. Trying to express more with a word than what it was meant to is maybe like trying to delegate two responsabilities to a function/class/etc. ;-)

    On a side note for your comment: of course if you make a public library, etc. then I cannot know what is dependant of it and can therefore say that everything that is VISIBLE is potentially DEPENDANT (I mean something else is dependant of it!). But that doesn't mean that VISIBLE ==== DEPENDANT. ;-)

    P.S. Of course there is surely some word that really have the same identifier and mean really different thing (as no relation at all).

  4. #204
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Let's say that component A defines a global variable in the $_GLOBALS array. Now, that same variable is visible to component B, but unless component B *uses* that variable, I wouldn't say that it is dependent on it. Same goes for functions and classes. Just because a class can *see* a particular variable, function, or class does not mean that it is dependent on it. Visibility != Dependency

    JT

  5. #205
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by seratonin
    Let's say that component A defines a global variable in the $_GLOBALS array. Now, that same variable is visible to component B, but unless component B *uses* that variable, I wouldn't say that it is dependent on it. Same goes for functions and classes. Just because a class can *see* a particular variable, function, or class does not mean that it is dependent on it. Visibility != Dependency

    JT
    Indeed Visibility != Dependency. But to be dependent on something it must be visible.

    And more importantly, in the case of say, a framework (where you are not the only one developing against it) anything that's visible, SHOULD be treated as possibly dependent.

  6. #206
    ********* 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 seratonin
    Let's say that component A defines a global variable in the $_GLOBALS array.
    That was why I tried to make clear what was meant by "visible". If developer pokes around the code to subvert the interface then all hell will break loose and they deserve what they get.

    I am now thinking that visibility is the precise word to use and not dependency, as long as the interface is clear. If the interface is not clear then we have more serious problems, but's that's by the way.

    The day you first publish a library there are no dependencies at all, whereas you have decided what is publicly visible. If you like the actual dependencies are an implementation detail, not something you take into account when designing the library.

    So what is visible?

    As it's not usual to publish the internal interfaces in any great detail you usually have to imply it from the structure of the code, test cases and sample applications. Obviously if an example has used the visibility (has a dependency) then you know for sure. In the absence of language features to force restrictions you have to go by the structure of the code. Any significant class that is created by the "new" keyword is clearly published as is any interface. I am groping for rules here to describe something which in practice is often very obvious.

    Meanwhile something else has struck me about this thread. It's all rather unreal. This is the first time in years I have had a discussion on encapsulation and the like. You just don't bother with this stuff when actually writing software as it's not useful. I pity someone new to OO and coming across this thread, being left with the impression that this stuff is in any way important, and then trying to figure it out at the edit window of a blank script.

    We are entering a world of new concepts and trying to come up with a legal definition. That's not how to learn this stuff. The way to do it is by example code and falling into some of the holes that this stuff is designed to prevent. The labels only have to be approximate pegs to enable discussion. Defining the meaning of a car won't help you drive one. This whole thread is a bit silly.

    The important stuff at the whiteboard is patterns, flex points, visibility, roles and the determination to understand and correctly name domain classes.

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

  7. #207
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    deleted

  8. #208
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    Here is your interface for a Person in your example application. This is not code writing by someone who believes in "Keeping it Simple Stupid" nor does it take into account massive amounts of Object Oriented Principles.

    There is some serious refactoring to do.

    PHP Code:
    class Person extends Default_Table {
        function 
    Person();
        function 
    getFieldSpec_original ();
        function 
    getValRep ($item 'star_sign');
        function 
    _cm_commonValidation ($fieldarray$orignaldata);
        function 
    _cm_getExtraData ($where$fieldarray);
        function 
    _cm_getForeignData ($fieldarray);
        function 
    _cm_getInitialData ($fieldarray);
        function 
    _cm_popupCall ($popupname, &$where);
        function 
    _cm_pre_getData ($where_str);
    }
    class 
    Default_Table {
        function 
    Default_Table ();
        function 
    deleteRecord ($fieldarray);
        function 
    deleteSelection ($selection);
        function 
    formatData ($fieldarray);
        function 
    getClassName ();
        function 
    getCount ($where);
        function 
    getData ($where) ;
        function 
    getData_unformatted ($where);
        function 
    getDBname () ;
        function 
    getEnum ($fieldname) ;
        function 
    getErrors () ;
        function 
    getExpanded ();
        function 
    getExtraData ($input) ;
        function 
    getFieldArray () ;
        function 
    getFieldSpec () ;
        function 
    getFieldSpec_original () ;
        function 
    getInitialData ($where) ;
        function 
    getLastPage () ;
        function 
    getLookupData () ;
        function 
    getMessages () ;
        function 
    getNavButtons ($task_id) ;
        function 
    getNodeData ($expanded$where=null);
        function 
    getNumRows () ;
        function 
    getOrderBy () ;
        function 
    getOrderBySeq () ;
        function 
    getPkeyArray ();
        function 
    getPkeyNames () ;
        function 
    getTableName () ;
        function 
    getValRep ($item$where=null) ;
        function 
    getWhere () ;
        function 
    insertMultiple ($fieldarray) ;
        function 
    insertRecord ($fieldarray) ;
        function 
    popupCall ($popupname$where$script_vars) ;
        function 
    popupReturn ($fieldarray$return_from$selection);
        function 
    setAction ($action) ;
        function 
    setDefaultOrderBy ($sql_orderby) ;
        function 
    setFieldAccess () ;
        function 
    setFieldArray ($fieldarray) ;
        function 
    setOrderBy ($sql_orderby) ;
        function 
    setOrderBySeq ($sql_orderby_seq) ;
        function 
    setPageNo ($pageno '1') ;
        function 
    setRowsPerPage ($rows_per_page) ;
        function 
    setSqlSearch ($sql_search) ;
        function 
    sqlAssemble ($where) ;
        function 
    updateLinkData ($fieldarray$postarray) ;
        function 
    updateMultiple ($fieldarray$postarray);
        function 
    updateRecord ($fieldarray) ;
        function 
    updateSelection ($replace$selection);
        function 
    validateDelete ($fieldarray) ;
        function 
    validateInsertArray ($fieldarray) ;
        function 
    validateUpdateArray ($fieldarray) ;
        function 
    _cm_commonValidation ($fieldarray$originaldata) ;
        function 
    _cm_deleteSelection ($selection) ;
        function 
    _cm_formatData ($fieldarray) ;
        function 
    _cm_getExtraData($where$fieldarray) ;
        function 
    _cm_getForeignData ($fieldarray) ;
        function 
    _cm_getInitialData ($fieldarray) ;
        function 
    _cm_popupCall ($popupname$where) ;
        function 
    _cm_popupReturn ($fieldarray$return_from$selection) ;
        function 
    _cm_post_deleteRecord ($fieldarray) ;
        function 
    _cm_post_getData ($rowdata, &$where) ;
        function 
    _cm_post_insertRecord ($fieldarray) ;
        function 
    _cm_post_updateMultiple ($fieldarray) ;
        function 
    _cm_post_updateRecord ($fieldarray$old_data) ;
        function 
    _cm_pre_deleteRecord ($fieldarray) ;
        function 
    _cm_pre_getData ($where_str) ;
        function 
    _cm_pre_insertRecord ($fieldarray) ;
        function 
    _cm_pre_updateLinkdata ($fieldarray, &$postarray) ;
        function 
    _cm_pre_updateMultiple ($fieldarray) ;
        function 
    _cm_pre_updateRecord ($fieldarray) ;
        function 
    _cm_updateSelection ($replace$selection);
        function 
    _cm_validateDelete ($fieldarray) ;
        function 
    _cm_validateInsert ($fieldarray) ;
        function 
    _cm_validateUpdate ($fieldarray$originaldata) ;
        function 
    _dml_deleteRecord ($fieldarray);
        function 
    _dml_deleteRelations ($fieldarray);
        function 
    _dml_getCount ($where);
        function 
    _dml_getData ($where);
        function 
    _dml_getEnum ($item);
        function 
    _dml_insertRecord ($fieldarray);
        function 
    _dml_ReadBeforeUpdate ($where);
        function 
    _dml_updateRecord ($fieldarray$oldarray);
        function 
    _dml_updateSelection ($selection$replace);
        function 
    _dml_validateDelete ($fieldarray);
        function 
    _getDBMSengine ();
        function 
    __sleep () ;

    Take a look at the common functions. Everything to do with meta data about an entity, put in some sort of TableMetaData object. Everthing to do with insert/update validation put in a Validation bject. Pass the validation object the TableMetaData object and the data to be validated. Everything to do with querying the database(setOrderBy(), setWhere() etc..) put in a query object and pass that object to the DAO.

    Having 100 or so functions in a class is a serious bad code smell. Doing these things and refactoring will drop the amount of code in your architecture by a ton.
    From Tony Marston's site:Large and Complex vs. Small and Simple

    Consider the following business requirements:
    The following functions are required for object 'A' (e.g. maintain customers or invoices)
    • Enter selection criteria.
    • List all occurrences that meet those criteria.
    • Create a new occurrence.
    • Display more details for a selected occurrence.
    • Update the details of a selected occurrence.
    • Delete the details for a selected occurrence.


    Where does it say that all these functions MUST be provided in a single component? It does not. Users may expect to see all that functionality in a single component, but only because that is what they have been used to in the past, or because it is the only option proposed by inexperienced designers. Neither party may be aware that there is an alternative which is actually easier to implement and just as easy, if not easier, to use.
    Hello World

  9. #209
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am looking at visibility in the context of scope and not in the context of an interface which a component exposes. I can see how visibility fits into a public interface. What is "public" is publically "visible". I also agree that when you make something publically visible something may depend on your public interface. But what if you access a component which accesses some other resource (e.g. RDBMS or Web service)? You are indirectly dependent on something that is not directly visible to you.

    JT

  10. #210
    SitePoint Enthusiast MickoZ's Avatar
    Join Date
    Jul 2004
    Location
    Canada, Qc
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah, lastcraft said stuff in his lastpost that is important. We can read, we can discuss theorically, etc. What is important sometime is to practice (but we cannot help, we like also the theory, there is a lot of strong personality in this discussion, therefore we could define the word we use in the beginning of any discussion to avoid any confusion, haha, how pragmatic is that? If only time was unlimited).

    Now just so this thread like to throw contreversy, I read two article and give them to you for fun:

    Allen Holub seem to be one of those who pull stuff we thought acquired (at less what is teacher in basic OO class/tutorial/etc.)

    Why extends is evil
    http://www.javaworld.com/javaworld/j...1-toolbox.html
    (Gosling also meant it apparently!?)

    Why getter and setter method are evil
    http://www.javaworld.com/javaworld/j...5-toolbox.html

    I cannot give any opinion on those, I just give it to you guys since those are also provocating topics, but maybe interesting. I did not even wasted the time to read the comments. If you have time you may want

    I got to know that from a Slashdot post:
    http://slashdot.org/article.pl?sid=04/11/16/1919215

    -----

    Now talking about pragmatic, that is a reason why I was often on Tony's side... Whetever he has separated his class, whetever he did it that way, whetever what... the question is, if you used his way to do, his codebase, will it helps? will it improves? there is probably a lot of what he did that is similar to what other people did. That is why I tried to entertain this discussion. We can talk about concept... about vocabulary... but in the end what I wanted to get out of this thread was comments like this: "I tried your architecture Tony... I tried to add one CRUD, I tried to modify this, etc. it tooks me X times, I believe with my method it will take X/Y time, etc." or comments that say this is better because, this is not better because. If X happen you are stuck. Then if X happen I am not stuck and I will do it that way and it does not take up that much time.

    Rather than fight about concept, etc. and we have a lot of capable people here for that, it will be nice to get some input that talk about if in REAL WORLD, if that works. I guess that could depend of the application of the architecture and then we cannot give a general answer (?)

  11. #211
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    From Tony Marston's site:Large and Complex vs. Small and Simple
    And your point is .... ?

  12. #212
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    And your point is .... ?
    I should really have quoted some of McGruff's post, as mine was a responce to it - though now a responce to something deleted. He quoted a passage from your site saying that you did not care what others though, so I made an attempt to reiterate a point made by Brenden Vickery using your own words.

    Quote Originally Posted by seratonin
    I also agree that when you make something publically visible something may depend on your public interface.
    I'm up for publically visible == possibly dependant. If you write an interface (PHP 5) for a class to use when working on another class (say a view of a model) you can use this to formalize the "gentleman's agreement", making the code more self-documenting.

    Douglas
    Hello World

  13. #213
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    I should really have quoted some of McGruff's post, as mine was a responce to it - though now a responce to something deleted.
    I started to say something then I just thought: "don't feed the troll".

  14. #214
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Damn I just can't stop myself.

    On this page I'm spoilt for choice but for example:

    One thing that really annoys me about articles and tutorials on OOP that I have found on the web and in books - they all talk about creating a class called 'shape' with various subclasses for 'square', 'circle', 'triangle' etc. This is of absolutely no use when I want to build a system to deal with real-world objects such as 'customer', 'product' and 'invoice' which have corresponding database tables. This has often led me to believe that OOP is therefore unsuitable for building common-or-garden business systems as it appears to have been designed for nothing but graphical applications.
    Could I ask you, Tony, to add a link to this discussion in your online "tutorials" (?). I'm scared that learners might be misled.

  15. #215
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And then I wandered into this.

    > Isaac Newton did not have to rediscover for himself a
    > thousand years of Science. He stood on the shoulders of giants.


    He had giants, I have pygmies.
    I'm speechless, quite speechless.

  16. #216
    SitePoint Enthusiast MickoZ's Avatar
    Join Date
    Jul 2004
    Location
    Canada, Qc
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Wow... that discussion looks interesting, what is interesting is that Marcus (lastcraft) was also replying there... I did not feel that those two ever communicated. I looked fast fast (not wanting to wast my time reading a pile of post) and I like how they began to talk about time it takes to "write"/"rewrite" part of the system... It is actually very interesting to get number...

  17. #217
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Back on the good/bad oop page:

    As far as I am concerned you bunch of tragicians [2] have taken a reasonable (note that I do not go so far as to say 'brilliant') concept called OOP and turned it into POOP (as in pooh, bowel movements, buffalo chips, compost, cow pats, crap, doo-doo, doggy-doo, droppings, dung, effluent, excrement, excreta, faeces, fertilizer, guano, jobbies, manure, muck, prairie oysters, road apples, sewage, turds [3]). Your petty rules are a hindrance to productivity rather than a help, so I suggest you take them away and flush them down the toilet where they belong. Instead of being OOPers you are POOPers [4].
    It's not mentoring he needs: it's a therapist.

  18. #218
    SitePoint Enthusiast MickoZ's Avatar
    Join Date
    Jul 2004
    Location
    Canada, Qc
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    McGruff, he has a nice poetic way to bash If that is his creation (surely inspired by other), it is a nice one. I like the enumeration style.

  19. #219
    ********* 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 McGruff
    And then I wandered into this.

    I'm speechless, quite speechless.
    I'd forgotten about this . My description of table mappers was a bit vague and I hadn't tried out the DataMappers at the time. That didn't work out so well. Amazing how much you learn in a year. We haven't even been working on persistence issues.

    yours, Marcus

    p.s. The persistence library described has been rewritten and is now open source and I am going to publish it here in a week or two.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  20. #220
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just to make sure: that wasn't aimed at you Marcus. Will be looking forward to the new library.

  21. #221
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    p.s. The persistence library described has been rewritten and is now open source and I am going to publish it here in a week or two.
    Something to look forward to.

  22. #222
    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 Tony Marston
    Not having view-related logic in a template? That sounds counter-intuitive to me. While there is logic inside an XSL template it is totally unrelated to business logic. It is simply the logic required to take the XML document and produce XHTML output, and without it the XSL stylesheet would be unable to function. I have not researched other templating systems (like Smarty, for example), but I imagine they work on the principle of "you give me the data and I will produce the HTML", so there has to be logic inside the template to process the data. The very idea of attempting to remove this logic from the template does not sound workable. If you have any logic that CAN be removed then what exactly is it doing?
    I can see that this needs a little bit more precision. I said that I wanted to keep view-related logic out of the template "as much as I can". That's because I want it to be as close to plain HTML as possible, and the reason why I want that is for the benefit of the Web designer who might edit the templates. Whether that is necessary is a discussion we've had several times in this forum and once before in this thread, and I wasn't eager to open it. That's why I just say that I respect your opinion even if it seems to differ from mine.

    There's a whole range of view logic from the simplest conditionals to the complex logic you would need to produce an event calendar page that can show simultaneous events side by side. And I'm just saying I prefer to implement as little as possible in the template language, whatever it might be.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  23. #223
    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 Tony Marston
    In all the documentation I have read on the 3-tier architecture the terms 'tier' and 'layer' have always been synonymous. Just bear in mind that there is 'physical' 3-tier as well as 'logical' 3-tier.
    My guess is that we're having a lot of phony disagreements based on the fact that different people have read different documentation. Here's Fowler's version of it:
    Quote Originally Posted by Martin Fowler, PoEAA
    When people discuss layering, there's often some confusion over the terms layer and tier. Often the two are used as synonyms, but most people see tier as implying a physical separation.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  24. #224
    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 lastcraft
    I am now thinking that visibility is the precise word to use and not dependency, as long as the interface is clear. If the interface is not clear then we have more serious problems, but's that's by the way.
    What started this was discussing what is required of a layered system. You haven't broken layering until you actually introduce an inappropriate dependency (or worse, mix up the code itself). What you seem to be saying, and you may be right, is that focusing on visibility is the key practical issue in maintaining a layered system.
    Quote Originally Posted by lastcraft
    We are entering a world of new concepts and trying to come up with a legal definition. That's not how to learn this stuff. The way to do it is by example code and falling into some of the holes that this stuff is designed to prevent. The labels only have to be approximate pegs to enable discussion.
    What I think is you have to fall into the holes first, then it can be useful to discuss concepts. And it's useful only if people are actually exploring in order to understand, rather than trying to prove they're right.
    Quote Originally Posted by lastcraft
    Defining the meaning of a car won't help you drive one.
    No, but if you want to buy a car you'd better make sure you get a car and not something else. That's easy, of course, but only because most of us have known what a car is since we were about two years old. Concepts like "visibility" are more difficult.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  25. #225
    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 Selkirk
    I take a more precise and limited view point of MVC that is closer to the original smalltalk definition, with the controller focused on input, and translating that input into operations on the model.
    It seems to me that trying to apply the original smalltalk definition to Web MVC is one of the main sources of confusion on the subject.

    But your point about being able to change from one template engine to another is a good one. If there's logic in the Controller that depends on the nature of the template engine, then that's a limitation in the design. But if it's easy to extract that part of the controller, then it's less of a limitation. If it's in a separate class or classes, then you could consider it nicely separated but poorly labeled.

    I couldn't care less about "valid" or "invalid", "right" or "wrong". What counts is how difficult it is to make a certain kind of change.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais


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
  •