Page 2 of 3

Posted: Sat Nov 11, 2006 2:17 pm
by timvw
From that site:
To develop a web system implementing the business rules of your customer, you've got to:

1. Know relational databases.
2. Know at least one server side scripting language.
3. Know javascript.
4. Know ajax.
5. Know html.
6. Know css.
But i've seen people build complete webapplications (some even pretty good too) without even knowing what the abbreviations stand for in that list...

Anyway, i've got the feeling that the rest on that site was written by a person (wanted to use a less nice word here :p) that doesn't have the slightest clue what he's talking about (not saying that their system can't be good). In that case i prefer to read more about radicore. (No no, don't tell me what you think about the autor of that framework :p)

Posted: Sun Nov 12, 2006 1:27 pm
by david2007
No! I'll tell ya what I think:

this MVC stuff is always involved around some framework or api

Who has time to keep learning api after api from projects you never know will be there next year?

I don't know about you guys... but when it comes down to large systems you got to have something to organize the system.

I develop in java too and I'm forced to use struts in my job. I hate it!!! you got to spend several weeks until you got experienced in that stuff and I'm not convinced it really pays off.

so, if you don't have to learn a new api, great!!!

Posted: Sun Nov 12, 2006 4:42 pm
by feyd
Ceasing to learn things, API or not, means I'm dead.

I generally don't have a problem learning a new API so long as it's documented somewhat decently. The act of not looking at other APIs means you gain less relative perspective. Less relative perspective often leads to not being able to judge APIs that suit not only your current, but future needs too easily, i.e. myopia. Which then leads to unemployment.

:)

Posted: Mon Nov 13, 2006 2:17 pm
by Ollie Saunders
APIs are easier to learn once you are familiar with OO and particularly design patterns. I remember looking at the IO class for C++, this was when the only other language I knew was pascal, and I completely didn't know where to begin. Now that I know its a decorator pattern I feel I would be able to look at the documentation for them and actually work out what to do.

Also APIs aren't limited by anything. A good powerful API may be easier to learn than a totally new system trying to achieve the same level of power.

Posted: Tue Nov 14, 2006 8:46 pm
by david2007
ok... but...

if you don't have to deal with any api, wouldn't it be easier?

from 8 years of experience and lots of apis and frameworks the bottom line for me is that web development really differs a lot from desktop development.

I don't think these guys are completely wrong and I was never quite a fan of simple things having to be done harder just to be "aesthetecally correct".

:?:

Posted: Tue Nov 14, 2006 9:27 pm
by feyd
If I don't have an API to work with, I'd likely have to write the underlying code myself or have to figure out what the underlying code does by probing it. That would take ages and just isn't even remotely feasible for most clients.

I don't want to get into a measuring competition so I'll stay away from the rest of your response.

Posted: Wed Nov 15, 2006 6:16 am
by Maugrim_The_Reaper
I don't think these guys are completely wrong and I was never quite a fan of simple things having to be done harder just to be "aesthetecally correct".
MVC and other OOP patterns are not simply to be "aesthetically correct". Yes, they complicate the basics, but for good reason. Once you learn the API and use cases, it becomes far easier to maintain what you write plus all the detailed stuff you shouldn't have to waste time on day after day, are buried behind an API that generally only changes slowly (if at all).

Posted: Wed Nov 15, 2006 11:02 am
by david2007
I've seen an API (besides php functions themselves) that really adds more value than complexity

"Once you understand the use cases" => takes some time and adds value for the customer
"Once you learn the API" => takes lots of time and does not add value for customer

After this discussion started I went behind some other MVC frameworks for PHP and, sincerily, they're all a pain in the ass.

There are xml descriptors, delegators, actions, blah, blah, blah

I takes time to learn those things and the return... man, I don't know.

I always feel I'm loosing my time on that. 8O

Posted: Wed Nov 15, 2006 11:45 am
by Christopher
I think david2007 has been trying to convince the folks over as Sitepoint about his Sybrain framework too ... with about the same results. I looked at the code and was unimpressed. And all of this stuff about "no API" I think is nonsense -- there is always an API. It seems like there is some misunderstanding of OOP and MVC, especially in PHP. That, mixed with bad feelings about Struts config files (which is the one part I can relate too ;)) and a dislike for how some PHP frameworks do things.

Posted: Wed Nov 15, 2006 11:57 am
by RobertGonzalez
I like Jason Sweat's reply. And McGruff's is pretty interesting.

EDIT | I should have posted the link to the Sitepoint thread that I am talking about.

Posted: Wed Nov 15, 2006 12:18 pm
by MrPotatoes
wow, that code is ugly as all hell

Posted: Wed Nov 15, 2006 1:05 pm
by david2007
feyd said:
"I don't want to get into a measuring competition so I'll stay away from the rest of your response."

Doesn't surprise me because I've never found ANY evidence proving this "content and logic separation" stuff is cheaper or has a better ROI than spaghetty code.

arborint said:
"I think david2007 has been trying to convince the folks over as Sitepoint about... "
I'm really rocking and rolling in other forums, but I'm asking questions to see what happens, not trying to convince anyone. But if you want to know my side up to now... I agree that OO and MVC doesn't fit to the Web.

"I looked at the code and was unimpressed."
Code has to be cheap and work, not to impress or make you fell better.

"And all of this stuff about "no API" I think is nonsense -- there is always an API."
In this case (sybrain), there is no API. they're even seem to be proud of that...

"It seems like there is some misunderstanding of OOP and MVC, especially in PHP. That, mixed with bad feelings about Struts config files (which is the one part I can relate too Wink) and a dislike for how some PHP frameworks do things."

I started as C++ programmer, then java, then web, then lately php. I know OO.
If I would start a game project or a spreadsheet project (desktop sofware), undoubtely I'd use OO:
1) everything is running under the same computer
2) there's UI libraries (provided by OS) common to all apps

What you got on the web?
1) a browser on another computer
2) html dinamically generated in another computer
3) scripting languages not OO oriented (please, don't tell me support to classes is OO!)
4) you can call pages directly (parts of the system) directly from the client!

Sincerely, there is no room for OO there.

MrPotatoes said:
wow, that code is ugly as all hell

Will your client pay you more because you did a "pretty code"?
8O

Posted: Wed Nov 15, 2006 1:45 pm
by feyd
Code reuse is what most of us are after. Spaghetti code does not help in the slightest toward reuse. The more maintainable code will often win further client work. This is especially true if you have to work with other programmers.

..and if you're using a library, you're using an API too.. Like it or not.

Posted: Wed Nov 15, 2006 6:45 pm
by Christopher
I have been reading these comments and they sound more like political slogans than ideas that actually make sense. A major premise presented is that "OO and MVC doesn't fit to the Web". That's a sort of nonsense sentence like "baking and electric mixers don't fit with evening meals". Throw together a methodology, a pattern and an application platform ... see look! they don't mix! I guess the words aren't big enough to fool me yet. ;)

Posted: Wed Nov 15, 2006 7:57 pm
by alex.barylski
So much for this being a supportive enviroment :lol:

David...I feel for you dude...but your ideas...they simply don't work...

Programming is all about problem solving and in problem solving it's always best to divide and conquer...decompose a problem into as many small problems as possible.

Modularity makes everything cleaner and clear. Mixing HTML with PHP or SQL or CSS, etc...just complicates things by virtue of being verbose.

Yes I can look at a file with no coding conventions, standards, policies, best practices, etc...but it's because of human cognition we *all* prefer to break a problem up into smaller parts...the human brain can only absorb so much before it chokes. Keeping things simple (as you put it) and seperate allows us to focus on "a" single problem at a time. Humans work best when uni-tasking not multi-tasking like a computer. ;)

Abstraction and modularity are two of the key elements in understanding and ultimately solving any problem of any nature...

If you can see the problem of MVC and can discover a solution as you have done...why not try and see it from the other perspective and improve on MVC rather than reinvent the wheel.

I'm agreeing with the majority here which is rare...in fact we all seem to have reached the unanimous decision that your idea is flawed - that right there should be an indicator something is wrong. :P

Cheers :)