Welcome Guest, Not a member yet? Register   Sign In
The Controlller and Model same filename -> wrong ?
#21

[eluser]jedd[/eluser]
drewbee, can't you make a comparably elegant replica of this approach by either looking at the context of the passed parameter, or by passing a second parameter that describes the type of the first?

For instance. With one of my lookup functions, I accept either the user's login_name or the user_id. It's a simple matter, at the start of the function, to identify if I've got a numeric or an alphanumeric input. If the latter, I do a lookup of user-ID based on login_name, and in both cases I then jump to a (private) function that looks up based on user_id. It's not especially extensible beyond these two cases, without getting into some messy and (long term) dangerous assumptions about data types .. but that leads to the second option I mentioned.

Second parameter, defines the type of the first parameter. Eg. $user = user_lookup ($id , "id") A simple switch statement could then farm out to dedicated and possibly private functions within your model.

Basically what you're trying to emulate is something a step beyond conventional method overloading (and two steps beyond PHP's interpretation of that feature).
#22

[eluser]jedd[/eluser]
Colin - I don't feel I've done an excessive amount of hoop-jumping here. The conclusions you suggest I reached I would have taken as predicates. I entirely agree with your observation wrt inclusiveness of clashes occurring regardless of intepretation of controller and model intents - so much so that I said as much in the message to which you were replying.

I'm not (yet) comfortable with gratuitously aliasing things. There are times, I'm sure, where this may be appropriate - but so far I've found it more elegant to design around what I consider to be such ersatz requirements.

Perhaps I'll yet be convinced of your approach, but right now I put User_model() in the same basket as naming my variables $x_int and $user_name_string.
#23

[eluser]Dam1an[/eluser]
[quote author="jedd" date="1242072265"]Perhaps I'll yet be convinced of your approach, but right now I put User_model() in the same basket as naming my variables $x_int and $user_name_string.[/quote]

You say that is if it was a stupid thing to do (and maybe you're taking it too far with that example)

But I work for a very large software company, and with GUI design (in Java) we have variable names like
Code:
textbox_email
checkbox_agree_t_and_c
etc

The reasoning for this, is you can then have a String called email (no string_ prefix) and you know its the contents of the email textbox

A few simple naming conventions like this can massivle speed up development and avoid confusion
#24

[eluser]jedd[/eluser]
Hi Dam1an - you are, of course, quite right. On larger projects - or rather, anything involving >1 person - I can happily acknowledge benefits from embedding context within variable and function names.

So far no one has suggested adopting an approach like: User_controller(), User_model(), validate_email_helper(), send_message_library() ... which would be the obvious (and comparably ludicrous to my earlier example) extrapolation.
#25

[eluser]drewbee[/eluser]
While were on this naming conventions wagon, something that I thought was rather intuitive in terms of naming conventions was the database column names at my current job. This job is the first time I have ever seen this, but it comes in real handy so you know exactly what data column type it is.

intAccountID, chvName, chvEmail, bitActive, fltPaidAmount etc etc.
#26

[eluser]Dam1an[/eluser]
[quote author="drewbee" date="1242084501"]While were on this naming conventions wagon, something that I thought was rather intuitive in terms of naming conventions was the database column names at my current job. This job is the first time I have ever seen this, but it comes in real handy so you know exactly what data column type it is.

intAccountID, chvName, chvEmail, bitActive, fltPaidAmount etc etc.[/quote]

I'm not sure I would find that to be as big a deal is you do
Partly because it just seems obvious (in 99% of cases) what type something is, anything with ID in it is always an int, stuff like email, name etc is a varchar, anything which sounds like a boolean, eg is_active is a boolean

Also, with PHPs dynamic typing, its not as important, as a string of a number can be treated as a string or a number
#27

[eluser]drewbee[/eluser]
Yeah, this is far more a big deal with Cold Fusion. It's very picky about data types. You cannot pass ints and strings or strings as bit etc. It has to be exactly what it is.
#28

[eluser]Myles Wakeham[/eluser]
My personal preference is to identify the 'logical' reason for the existence of the Model and name it accordingly. What I mean by this is that I use Models as a basic ORM layer between the database and my application, and in that context they are pure classes.

Since I will instantiate from them, I want to make sure my code is logically readable. I've adopted a data modeling standard for this, since the model classes are OO representations of the database objects for me. This means I use singular referencing to the model, and in the case of controllers which are purely the UI version of this, if I run into a situation where the controller shares a common name with the model, I just make it a plural version.

For example, a 'Client' is represented as a singular entity in my database table. It is mapped to my CI application as a Model class called 'Client' (singular). But in the case where I offer functionality through my app to work with the client (ie. Add one, Delete one, etc.) I reference it as 'Clients' in the controller.

The goal for me is that anyone can read my code and its plain and simple. Since my projects don't seem to be getting any smaller these days, I'm assuming 4-5 developers on the one project with SVN, so each needs to be able to read each other's code base without too much confusion. Adding the word '_model' to a class isn't something I have done, because I wanted to be able to have something like:

Code:
$this->client->check_account_balance()

since it just reads easily. In the case of referencing the instantiated objects in plug-ins or helpers, etc. I create a handle to it that has 'the_' prefixed, so in those cases they read:

Code:
$the_client->check_account_balance()

Again, its all for readability.

My ultimate goal is to be able to have a real vacation where I'm not having to be a slave to my own code creations and I can give it to any other CI/PHP developer and its somewhat self-documenting. I've come to this position after decades and decades of coding experience where I can attest that maintaining code that isn't written this way is just a really bad way to live one's life. These little habits so far have served me well, but if anyone has any suggestions for better ways I can do this (and hence improve my quality of life) I'm all ears.

Myles




Theme © iAndrew 2016 - Forum software by © MyBB