SitePoint Sponsor |
|
User Tag List
Results 101 to 125 of 274
-
Nov 13, 2004, 17:08 #101
- Join Date
- May 2003
- Location
- Calgary, Alberta, Canada
- Posts
- 275
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Can you change the name of a column in the database and only change the 'data dictionary' in one place?
Originally Posted by Tony Marston
PHP Code:$table_id = 'person'; // table name
$title = 'List PERSON'; // form title
$screen = 'person.list.screen.inc'; // file identifying screen structure
$button_text = 'Person';
// identify extra parameters for a JOIN
$sql_select = '*';
$sql_from = 'person '.
'LEFT JOIN pers_type ON (person.pers_type_id = pers_type.pers_type_id)';
$sql_where = '';
// set default sort sequence
$sql_orderby = '';
What happens if you change the name of the person table? Does this code need to be changed?
What happens if you change the pers_type_id column name? Does this code need to be changed?
What happens if you change the way a person is related to a person type in the database? Would this code need to be changed?
Maybe I didnt see the code that would make these changes but if your answer to any of these questions is yes then your layers are mixed up.
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Last edited by Brenden Vickery; Nov 13, 2004 at 18:20.
-
Nov 13, 2004, 17:46 #102
- Join Date
- Jul 2004
- Location
- Canada, Qc
- Posts
- 42
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Go directly there:
http://www.tonymarston.co.uk/sample/person_add.php
There navigation is gone... :\
Maybe that is why people use a front controller *g*
-
Nov 13, 2004, 18:20 #103
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
Tightly honed classes create a system which is in fact easier to maintain precisely because they are tightly honed. If you get that right, at some point you find that instead of writing swathes of new code for every task, you can often simply aggregate existing classes in a new way.
http://c2.com/cgi/wiki?CouplingAndCohesion
Lean & mean classes should also be easier to test.
-
Nov 13, 2004, 21:11 #104
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by AWilliams
These days if the concept of a User can be described quite adequately as Login or AccessKey and Authorisor (my current favourite) then I'll go that route. If there is contact details to be added later then I will likely add them as an Account and then split that later if accounts can have shared contact info. Something like...
Party (Person or Company) (1)<-->(*) Account (1)<-->(*) AccessKey
Access key is both the username and password together on that kind of system, but may be an MD5 key on a SOAP server or a token from an SSH keychain.
I have only once needed all entities (Party, Account, AccessKey), but it's nice to have a clear refactoring route when things start to get complicated.
Originally Posted by AWilliams
. With the arrows signifying visibility (dependency)...
User --> UserAccessor --> Database
User <-- UserMapper --> Database
User (ActiveRecord) --> Database.
That switch of visibility is the distinguishing feature. The trick of turning ActiveRecord into DataMapper and so switching the arrow is known as DependencyInversion.
Also if you are doing a mostly passive data (i.e. reporting or CRUD) application then also...
Widget --> ResultSet, Connection --> Database
Because you only have one domain object (ResultSet) all of your display code can be written just once. This is the Delphi/VB client-server approach and is spectacularily efficient if the domain logic that can affect the flow of code is limited.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Nov 13, 2004, 21:35 #105
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by JNKlein
.
Actually we are developing a slimmed down persistence layer which I have shown to a few selected people. You can have a private copy if you are interested. The current project owner (Mike Mindel you hero) has agreed it to be open sourced and we should be publishing it shortly. It's more of a proof of concept right now than a working system and we want to do some more refactorings before we go completely public.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Nov 13, 2004, 22:28 #106
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by MickoZ
For a tiered app. adding a field to a view would require a method on an application object (also common sense of course).
That method could do a calculation from other information though. It could aggregate information from completely different domain objects (for example a shopping basket view adding shipping costs). It could do lot's of things. What it does at the domain level should be shielded from the view.
As we descend further, even if it was just adding a new property of the domain object we should still not know the table schema. So it could be joined in from another table, a stored proc, or maybe it's not even in a relatonal database (an image say). The schema is invisible from just looking at the domain objects' interfaces.
The definition of tiering is that each tier can only see the one immediately below. The full architecture is sometimes called 4-tier (Presentation, Application, Domain, Infrastructure), but there are slightly different interpretations. When Application and Domain are combined, that is the traditional 3-tier. I find the 4-tier model a better diagnosis tool, although tiering (layering) is a pattern and as such you adjust it to taste.
Anyway, if changing the DB schema causes a change to the view you obviously don't have tiering. If changing a view (without adding a new application feature) causes anything at all to change then you don't have tiering. If changing a domain interface causes the schema to be edited even though the relationships are essentially correct, then you don't have tiering.
Except that things aren't that simple.
In practice we take some shortcuts if they are expedient. An example is making the table names and class names synonymous (called an isomorphic mapping). This can make the architecture easier to understand on the ground and can save mapping code. If we are the only application or domain library using the DB then there is no problem with this. If a problem does arise, then you will have to put in the mapping code.
As an aside, once you get low enough in the architecture it's not actually that easy for developers to do much damage to a project. As long as the presentation is safely isolated then the refactoring work can often be done in a matter of days even in the face of a complete about turn. For example changing a DataMapper architecture to a DataAccessor one took 4 pair/days on a previous project.
Summary:
Yes you have to make it logically possible for a new piece of information to be displayed. Tiering allows us to choose the "how" of that process with complete freedom. You don't have to add a corresponding database field.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Nov 13, 2004, 23:05 #107
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Tony Marston
PHP Code:$contact = &$person->getContact();
$contact->send($message);
Originally Posted by Tony Marston
You have a client/server app., not a three tier one.
Originally Posted by Tony Marston
You really, really should read the enterprise patterns books.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Nov 13, 2004, 23:14 #108
- Join Date
- Jul 2004
- Location
- Canada, Qc
- Posts
- 42
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I never did heard the CRUD (CReate Update Delete) acronym. ;-)
I guess it depends how you work too... but of course if I go on and rename an attribut of an object... of course, we can always make this backward compatible, but sometime we will want for code understanding to rename the field everywhere. ;-)
This is often the case when you did get the vocabulary or the design wrong in the first place. But let's say vocabulary mainly, and for some reason you are picky and you want to use the good term in your attribute, etc. You will eventually want to update your view (deprecating probably the thing that let the view communicate with the old structure vocabulary, i.e. a method).
Is there one of those persistance pattern that you would suggest for beginning (I guess I tried myself some of them in a prototype of a software I am doing, but I have changed between each of my concept of coding style on purpose since it was a prototype, that of course evolved and evolved, even thought I planned rewrite since beginning and I funnily just stumbled across an article of you that talked about rewrite/fix)
However, I would like to know of a clean way. Maybe the solution for me is to study the different way that exist.
DAO, DataMappers, etc.
I want something very flexible and if possible the most simple as possible. Note: there is some complex logic/structure in the apps. It mights even go torward a R/D project ;-) that is where my client is going forward to... but if everything go success, I will probably have to do something more solid than some prototype code and I am trying to get some knowledge on building better architecture and using the intelligence that have been put in the past of course... (I like do-it-myself, but I guess more I will advance I will have to accept the time-constraint and to use what other have worked for!)
-
Nov 14, 2004, 07:19 #109
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by MickoZ
-
Nov 14, 2004, 07:39 #110
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by MickoZ
-
Nov 14, 2004, 07:44 #111
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by MickoZ
The trouble is that different people like different words, and there is no way to please everybody.
-
Nov 14, 2004, 07:53 #112
- Join Date
- Oct 2004
- Location
- downtown
- Posts
- 145
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
TransformView (the XSL) makes it difficult for graphic designers to edit pages without developer intervention. With a TemplateView and Widgets they can be dragged around in Dream Weaver and the like.
You really, really should read the enterprise patterns books.
I've used the Template View pattern (and Composite View) and I find that likewise you can put logic in a database, you can also put (certain) logic in a stylesheet. This helps to simplify things some what, and to a degree, gives easier maintenance.
-
Nov 14, 2004, 10:41 #113
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Version0-00e
If you are mainly displaying tables and lists only then having a Widget to do the job makes sense. If you have that arrangement then the transform view complexity can be pushed into the Widget, simplifying the presentation.
They have trade-offs and you weigh them against each other at the time.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Nov 14, 2004, 11:05 #114
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Brenden Vickery
Some developers seem to think that directly accessing class variables breaks encapsulation, but see these articles for a contrary view:
Do you also agree with the person who says that Inheritance breaks Encapsulation?
Originally Posted by Brenden Vickery
Originally Posted by Brenden Vickery
Similarly my presentation layer, which is responsible for building all the HTML screens, *must* have some knowledge of what fields need to be displayed, in what order, with what labels and with what controls. You cannot add a field to the database and have it magically appear in the relevant screen exactly as you, or the user, want it. If you can then I would love to know your secret.
Originally Posted by Brenden Vickery
Actually, I am not totally happy with that way of doing things, but my problem is this: by default each business entity can only access a single table, but certain transactions which access that business entity may require it to perform either a simple or a complex JOIN. Therefore it is the choice of transaction which governs which JOIN statment to use. As the transaction is a presentation layer component the request for a particular JOIN must come from the presentation layer, pass through the business layer, and be executed by the data access layer. I could get the presentation layer to say "give me join number 21", but I'm even less ahppy with that idea. How would you handle this in your infrastructure?
Originally Posted by Brenden Vickery
That may not be the proper way according to your rules, but it works! In my humble opinion it is far better to have something which breaks some arbitrary set of rules but which works than it is to have something which obeys those rules but which fails to work.
-
Nov 14, 2004, 11:12 #115
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by MickoZ
-
Nov 14, 2004, 11:26 #116
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by McGruff
I have worked on a system where the architects chose to have ten layers of abstraction instead of three, and guess what! It was a total disaster as far as the developers were were concerned. It was so complicated and difficult to debug that it took weeks to build even a single component. The client was so impressed that he cancelled the project. I built ny own version of the same architecture, but restricted myself to only 3 layers instead of 10. The developers loved it because they could produce components in hours instead of weeks.
So my personal experience of systems with more layers than necessary is that they are to be avoided like the plague, and I'm afraid that my personal experience outweighs everybody else'e opinions by a large margin.
-
Nov 14, 2004, 11:52 #117
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Then why do you and others keep telling me that if I cannot change my database schema without changing my business and presentation layers then I don't have tiering?
If I add a field to the database then I must change the view otherwise it wont't be displayed. I must also change the business layer otherwise it won't be validated.
FYI adding a new field to a view in my infrastructure does not require adding a new method to a business object.
Originally Posted by lastcraft
Originally Posted by lastcraft
-
Nov 14, 2004, 12:21 #118
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
With my approach all the User class does is satisfy a request for data, and what happens to it after that is a matter for the controller which may pass it to a view of its choosing. That data may be output to a screen, written to a PDF file, used in an email message or added to a SOAP request. Surely how the user data is processed is not a function of the User class itself, but of a separate view object?
Originally Posted by lastcraft
- Presentation logic = User Interface, displaying data to the user, accepting input from the user.
- Business logic = Applying business rules, ensuring the data is valid before being pased to the database.
- Data Access Logic = Database Communication via the relevant API's.
Having a separate data access layer means that you can switch from one DBMS engine to another without changing any logic in the other layers.
Having a separate presentation layer means that you can change your user interface without having to make any changes in your business or data access logic.
The 3-tier architecture was promoted in the language I used prior to PHP as it made it possible to have an application with a client-server interface and to enable it for the web simply by adding on a new HTML interface which could share all the existing business and data access logic.
In case the significance of this has escaped you, it means that a 3-tier applicaton has exactly the same structure whether it has a client-server interface or a web interface, or even if it has both at the same time. You do NOT have one version of the 3-tier architecture for client-server and another version for the web. It is the same architecture, but with different presentation layers. As my presentation layer produces HTML output and runs off a web server, it is most definitely a web application.
Originally Posted by lastcraft
-
Nov 14, 2004, 12:21 #119
- Join Date
- Jul 2004
- Location
- Canada, Qc
- Posts
- 42
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
I think CLOSE is not bad. That is a part of the reason why I suggested that the choice be repeated too...
If it was repeated:
- no choice and click the action bouton = put no choice in the field
- no choice and want one, choose one than click the action bouton
- 1 previous choice and you don't want to change it... click that action bouton (whetever name, maybe keep the choose only).
- 1 previous choice and don't want it (an option to take no choice at all (radio or a bouton that unselect)
- 1 previous choice and you want to change it, change it and click the action bouton...
I guess I pretty much covered it. It may annoy people to get pragmatic and give suggestion but I guess it can be a good idea, since in your apps, what you try to do is give a generic way to do all similar operation (which is very interesting but hard to please everyone and HARD to please all possibility)
-
Nov 14, 2004, 12:34 #120
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Version0-00e
-
Nov 14, 2004, 12:52 #121
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Except, it appears, when it's MY garden when I am vilified for daring to be different. My motto is "innovate, don't immitate", so I will always look for a different way, a better way. If some people regard me as a heretic for daring to question their view of the universe, then so be it.
-
Nov 14, 2004, 13:01 #122
- Join Date
- Oct 2004
- Location
- downtown
- Posts
- 145
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Can you do the same thing with other templating systems?
The original design had a few failings I admit though the redesign solved the problem. In fact I was searching for the thread I had started originally for the script to post on this thread but couldn't find it
I still feel your apparant MVC design is flawed in some way or another though I can give a big thumbs up for what your doing with XML and XSL stylesheet at least
-
Nov 14, 2004, 13:07 #123
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Version0-00e
-
Nov 14, 2004, 13:24 #124
- Join Date
- Jul 2004
- Location
- Canada, Qc
- Posts
- 42
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
Of course that part of your apps is mainly for an "admin section" or a data management section. In a public website, we cannot 100% force the user to pass thru the admin screen, unless you redirect the person to the first screen if the session is not open, etc. There is always a way to do it ;-)
-
Nov 14, 2004, 13:48 #125
- Join Date
- Jul 2004
- Location
- Canada, Qc
- Posts
- 42
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
---------------------------------------
For "single choice popup"
You should have the option:
Selections: select none (which is similar to unselect all which you may want to keep) but select all has no sense in that context (if that is easy to define those behavior from the CONTEXT, then it is worth to at less remove the select all and maybe put a more appropriate label for the unselect. "unselect choice" who know. ;-)
Also the validation of the popup force you to select something and give the error "Nothing has been selected". That is just a thing to considerate and I cannot say it is wrong or bad. However if some popup are for optionnal choice, I would like the submit to accept a "no choice" as input data, but that is probably a trivial change in your apps/validation.
After doing those kind of change, all you have to do is to make something that allow people to drag and drop component, etc.I wonder if Microsoft.Net has bring its VB feel (probably with their event driven, that I know they did) with .Net editor...
Bookmarks