Are today's major frameworks capable of enterprise capable applications?

[DaveMaxwell]

@RavenVelvet

Performance wouldn’t be improved by retrofitting an autoloader but application security would be. None of those require_once statements appears to be wrapped in an appropriate is_readable(), which would allow for a graceful failure in the event that one of those files can’t be read in by the server process.

Unless there’s an appropriate error handler implementation elsewhere in radicore, the thing just falls over when it can’t require a file - potentially yielding filesystem paths to the browser. Unless all of those .inc files are outside of the web root (or the server’s set up to deliver .inc files as php), that’s a serious issue.

Even just replacing the require_once’s with a custom loader function would be a vast improvement.

Thank you! That’s exactly what I was asking for - that’s a quantifiable, definable benefit to justify at least considering the effort required to change over to this approach…

[TomB]

Just to be clear I wasn’t suggesting tony change his existing code my objection was at Tony saying “I don’t use autoloaders because I don’t have the problem they solve.”

Had he correctly stated “I don’t use autoloaders because my code is poorly organised, difficult to change without breaking things and i dont want to go rooting around in 9000 line files so I don’t want to mess with it” I wouldn’t have argued with his premise.

[s_molinari]

@RavenVelvet

Even just replacing the require_once’s with a custom loader function would be a vast improvement.

Oohhh…now you have me sitting on the very edge of my seat … Where is a popcorn icon, when you need one? Well I found these. Lollipopcorn. LOL!

Scott

[cpradio]

@s_molinari

Where is a popcorn icon, when you need one?

close enough?

[cpradio]

You go always go with this image instead

[RyanReese]

@cpradio Do you even Internet? This is the standard popcorn image
http://static1.gamespot.com/uploads/original/986/9866256/2608343-5469198052-XPfCp.gif

[cpradio]

@RyanReese

Do you even Internet? This is the standard popcorn image

Can’t see it Proxy is blocking it… waiting for the auto-download feature in Discourse to kick in and load it via a relative path… come on Discourse!!

Seems there are a lot to choose from:
https://www.google.com/search?q=image.google.com+popcorn&espv=2&biw=1280&bih=909&source=lnms&tbm=isch&sa=X&ei=oFc2VaqsBJLUoAS9g4HQCA&ved=0CAYQ_AUoAQ#tbm=isch&q=popcorn+gif+imgur&revid=1029747522

[s_molinari]

Oh boy, did we need some comic relief here or what! LOL!

Scott

[cpradio]

I’ve been trying hard to get a plugin here called ReplyGif, it would add a button in the composer to let you choose an animated gif that best fits what you want to say

One day, this will become a reality!

[RyanReese]

@cpradio

I’ve been trying hard to get a plugin here called ReplyGif, it would add a button in the composer to let you choose an animated gif that best fits what you want to say

[oddz]

@TomB

Had he correctly stated “I don’t use autoloaders because my code is poorly organised, difficult to change without breaking things and i dont want to go rooting around in 9000 line files so I don’t want to mess with it” I wouldn’t have argued with his premise.

I’ll drink to that!

[myesain84]

@tony_marston404

That case does not exist in my framework. My code has always specified a “require” statement just before a new class is instantiated. Remember that I wrote this code several years before autoloaders became available, so I have solved this problem in the “old fashioned” way. Just because the fashion has changed does not mean that I am going to refactor working code at a huge cost for zero benefit.

@tony_marston404 - I didn’t indicate that you should refactor your application framework to take advantage of autoloading. I specifically wanted to show that the problem an autoloader solves is not the fact that there exists a “long list of includes”. The existence of an include or require statement in a script doesn’t prevent a developer from effectively using an autoloader.

In response to a comment I made on a separate thread, you said this:

@tony_marston404

and you will never convince me otherwise

I think the rest of this community has decided that there is no point in trying to convince you that modern programming practices are beneficial, so personally, I will not do that anymore.

What I will do, however, is ask you to respect the intended audience for these forums. If you take a look at the About Us page for SitePoint, you’ll find this as the mission statement:

our mission is to deliver new ideas, emerging concepts, and teach state-of-the-art technology to our readers

You have used certain techniques to solve the issues being discussed. However, a visitor to SitePoint (e.g. those interested in new ideas, emerging concepts and state-of-the-art technology), is not the audience to whom the merits of these techniques should be discussed.

Whether or not your framework can be deployed as a viable enterprise solution is not at question here. You’ve been able to do this successfully for a decade, so that is not in question. This does not mean that modern programming techniques are not beneficial or that there are not opportunities in your code base to apply these techniques.

For the record, the state-of-the-art in PHP programming includes things like:

• Dependency Injection
• Namespacing
• Auto-loading
• Not implementing a Singleton design pattern
• Favoring composition over inheritance
• Modular composition

Of course this list is not exhaustive, but over the course of the last few weeks I’ve witness you argue against all of these items. My concern with this is that a visitor to SitePoint who is interested in staying up to date on programming concepts (e.g. those interested in new ideas, emerging concepts and state-of-the-art technology) will receive mixed messages regarding what’s acceptable and how a concept should be employed.

I imagine you’ll want to argue about how the modern practices are un-necessary and don’t offer valid benefits because you’ve been able to solve the same problems your own way. Again, this is not a commentary on your framework or how you have solved a problem in the past. It would be best though, to focus on how to employ new ideas, emerging concepts and state-of-the-art technology.

If you’d like to continue the discussion that has been had thus far, perhaps you could spin up a forum on your own website where it could continue.

[fretburner]

I think a big problem with this discussion is that it’s possible to go round and round debating about what certain terms and concepts mean or how they should be implemented… it’s too theoretical. One of the core arguments that Tony seems to make is that it doesn’t make good business sense to implement newer language features or implement what some consider ‘best practices’, as they would bring no advantages.

What would be ideal would be a way to assess the practical application of the approaches advocated by each side. It would be interesting to take a specification for a small application and have Tony and Tom / Scott build it using their chosen practices and then compare the time taken (and perhaps some other metrics). Then, the next step would be to introduce a change in the requirements and see which ‘team’ can implement those changes in the least time. I know it’s not likely to happen, but I think it would help to show whose methodology/programming practices provide demonstrable, practical benefits.

[Mittineague]

@tony_marston404

So you support my view that retrofitting autoloaders into an existing large application would not be cost effective?

I tend to be more an idealist than a pragmatist. i.e. I want my code to be “perfect”.
But the reality is there aren’t enough hours in a day and I won’t live enough lifetimes to do everything I’d like to do let alone go back to fixing up my older code.

As much as I cringe when I see members here say something like “but my FrontPage / DreamWeaver code works” there is something to be said about something “working” as horrid as it might be to some.

As I said, there comes a time with aged code that it will need to either be abandoned, rewritten, or patched.

Life is only so long, more so if you are working under a deadline, and sometimes one has to compromise “would be nice to have” with “good enough”

[oddz]

Not to mention in the real-world it is difficult to quantify the value of large refactoring efforts unless there is also some type of functional or visual update associated with it. You can’t just say to most suites you are going to spend 3 months time refactoring/rebuilding something but nothing will change but underlaying code. It just isn’t realistic or cost effective unless of course it is done in parallel with solving specific business problems that can be quantified.

[Jeff_Mott]

This topic (and others) probably would have gone better if we had distinguished between new and legacy applications. Whether it’s a good idea to use X when starting from scratch is a very different question than whether it’s worth the effort to refactor X into an existing codebase.

[TomB]

Of course an extension to that is the question “should you use a legacy codebase on a new project?”

[s_molinari]

Getting back on topic. Has anyone worked with a framework to build an enterprise/ LOB application, other than Tony? If yes and possible, can you explain a bit about the application and what framework was used?

Scott

[tony_marston404]

@RavenVelvet

But you haven’t actually solved the problem, you’re just ignoring it and relying entirely on the happy path.

You do not understand simple logic, do you? Having something and having a problem with something are entirely different situations. I do not have a problem with writing include/require statements, so I do not need any sort of solution to help with that writing of include/require statements.

[tony_marston404]

@DaveMaxwell

TomB:Just because you’re choosing to use old software still doesn’t invalidate the fact that you have the problem autoloaders solve. You just solved it a different way. You could use autoloaders to solve the problem.The problem exists in your codebase with a solution. You have the problem autoloaders solve.

OK, perhaps I’m being a bit pedantic here, but from a pure development perspective, a problem that has a resolution is no longer a problem.

Or are you saying that autoloaders provide enough benefit to warrant a (from his perspective) large scale effort to change over to using it? Is there a high enough performance increase to going in and changing JUST that? Or is it just a “it’s now a best practice, so you MUST use it?”

Best practices are great, but it’s often hard to justify a mass scale effort with no quantifiable benefit other than some reduced future maintenance when there’s payable work needing done.

Thank you for adding a sensible comment to this discussion, one based on common sense instead of unadulterated dogma.