CUTCODEDOWN
Minimalist Semantic Markup

Welcome Guest
Please Login or Register

If you have registered but not recieved your activation e-mail in a reasonable amount of time, please use our Contact Form for assistance. Include both your username and the e-mail you tried to register with.

Author Topic: To Route Or Not To Route - The Definitive Guide???  (Read 332 times)

benanamen

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +6/-0
To Route Or Not To Route - The Definitive Guide???
« on: 6 Nov 2020, 12:04:12 pm »
Jason, if you would, please provide download of complete basic code for a couple page static site as a base for discussions on "To Route Or Not To Route " that implements the architecture you oft talk about that does not use routing as it is commonly understood to be.

Based on your previous posts I would expect the example would contain:

1. A single point of entry ("One Index to rule them all" as you say)
2. Handling of "templates"
3. A directory structure of some sort.
4. No router as it is commonly understood to be

A couple pages would be sufficient to start. My point of discussion is how well your proposed architecture would scale to a large/very large site/application and what problems their may be and your solutions to those problems if any.

One reason I was hoping to see a crud application is that it contains "standard" complexities of most web applications and would surely be part of a large website/application. I guess we can get to that as we go along.

Me providing a router implementation is pointless at this point since I, in theory want to buy into the architecture you are selling for my large application but I am not sold yet.

If it helps, lets do this... Consider me a potential new client bringing a multi-million dollar account if you can land me. I have concerns on the architecture I know you would propose. Show me a simple example of the structure for me to demo. Address the concerns I may have after seeing it and hopefully you will land my account. I come to the table with open eyes and ears.

My initial position is that I would agree that your architecture would be fine for a small to medium site/application but I believe it would be problematic for a large scale application. (Not to say that adding routing is the sole solution). If you would like to really play the roles I can write you a mini RFP. Lets have some fun with this and see what we all can learn.

Aww heck, heres my RFP.

 *********************************************************
Request For Proposal 11-06-20

Greetings Mr. Jason,

I am Mr. Benanamen from ABC Company. We desire to build a large to very large enterprise website application. Our budget for this project is 5 million dollars.

You come very highly recommenced with many references. We understand you would propose a router-less architecture. We are concerned it may be problematic for a project our size.

We would expect our project to follow basic programming principles such as DRY (Don't Repeat Yourself) and KISS (Keep it Simple Stupid).  We would expect the site to be easy to update and maintain. Our employees are not very technically oriented. I am sure you come across this often.

Please provide a simple working static example of your architecture for review. We will follow up with any questions or concerns.

Sincerely,
Benanamen
ABC Company
To save time, let's just assume I am never wrong.

John_Betong

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +4/-1
    • The Fastest Joke Site On The Web
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #1 on: 6 Nov 2020, 06:07:00 pm »
Excellent question and looking forward to seeing constructive replies... especially since I am trying to refactor an old project that has a multitude of “I’ll just add this...”
Retired in the City of Angels where the weather suits my clothes

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 523
  • Karma: +90/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #2 on: 7 Nov 2020, 10:46:25 am »
First off I've got some work on the bench (phsyical PC repairs) to clear before I can toss together a quick standalone of a full static that's "vanilla" enough. I could just toss up an existing site, but I'd rather "dumb down" and use more verbose code to explain it clearly.

A couple pages would be sufficient to start. My point of discussion is how well your proposed architecture would scale to a large/very large site/application and what problems their may be and your solutions to those problems if any.
Which is why I'm interested to hear what you think, becuase I HEAR that claim a lot, that there's some sort of BS about it "scaling large" that is a "wah wah, it is because we say" that I never hear backed by a single fact or logical/rational thought. If anything, routing crap is oft so complex -- or at least what I encounter people calling routing -- it's THAT which is the slow, bloated, hard to maintain mess... because it's more code, and an attempt to shoe-horn every request into a single programming model, without simply using the request itself AS the model. If that makes any sense...

One reason I was hoping to see a crud application is that it contains "standard" complexities of most web applications and would surely be part of a large website/application.
Which to me sounds like over-complex over-thought answers to simple problems. Hence why most codebases where people call it "CRUD" or talk about "Routing" seem like two to ten times the code in as painfully and pointlessly complex a manner as possible.

My initial position is that I would agree that your architecture would be fine for a small to medium site/application but I believe it would be problematic for a large scale application.
Whereas if this is for a website, the term "large scale application" shouldn't even apply, and reeks of bloated inefficient crap that probably tells large swaths of users to go **** themselves. The attitude I hold towards 90%+ of the things people are calling "web applications" right now. Utter and total shite that does more harm than good to clients and often why I get called in to fix things in the first place!

I think we're light-years apart in mindset and mentality when it comes to solving client's problems -- or we're simply dealing with different problems from the start.

Hell, my response to the proposal request would probably upset you, as it's part of my client filter.



Mr. Benanamen

I find some statements and questions in your request troubling, as it indicates the possibility you have overthought and overscoped your project without actual planning or concern on what it is you really want to do. The lack of information of intent makes it difficult to even come close to putting together a proper proposal.
        -
In particular, the use of marketspeak doubletalk such as "large to very large enterprise website application." indicates that you are likely going to be building systems that alienate large swaths of users, either through a lack of focus, pointless layering of shortcuts, or just plain accessibility failings. The concept of a "website application" has become near synonymous with telling visitors to websites -- particularly those with accessibility needs -- that they are not welcome, and to that end I would require very specific details on why you think you need an application and what the data is.

Much less that since I also work both as an accessibility and efficiency consultant, the mere use of the word "application" and "website" in the same sentence indicates a failure to grasp what websites are and/or are for.

Same for the "project our size" notion where most of the time even the "largest" of projects shouldn't be that "large". If they do end up so, it is typically through developer ignorance, incompetence, or ineptitude. Simply put, people making websites who have no business even being involved in the process.

As to your staff not being technically oriented and/or ease of updating and maintaining? If this is a multi-million dollar project FLIPPING HIRE SOMEBODY!

In fact, that statement alone is making me considering rejecting your request.

With all due regards,
Jason M. Knight
Paladin Systems North



... and I have sent replies to potential clients that read exactly like that. You have all the telltales in there of people who aren't worth the headaches or time of working for.

Just like how the reply to the most recent proposal I sent to a company had me kick them to the curb as they were willfully negligent which is what got them in trouble in the first damned place, and then were willfully fighting of the necessary changes to get them out of trouble. So I willfully told them to hit the bricks until they were willing to make the changes to stop them having their arse sued off.

And they too had this "large enterprise website application" bullshit over something as simple as  a flipping banking portal.
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

benanamen

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +6/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #3 on: 7 Nov 2020, 11:32:43 am »
Mr Jason,

Thank you for the reply to our RFP.

To clarify, the proposed project is a "web based" business application to run all aspects of a large construction business. Since it is on the web, the term "website" fits as it will have a public "face" for the organization as well as a back end business application. Since it will run every aspect of our company, I think the term "Enterprise Application" is appropriate.

This application will handle payroll, employee management, Sales, Orders, Warehouse operations, Contractors, Sub Contractors, Properties, Supplies, Materials, Multiple office locations, Vendors, Billing, Accounts Receivable, Inventory Management, Human Resources, project management, IT, Marketing & Advertising, Building Maintenance and more. All the typical things you would find in a large company with 500 employees and multiple locations plus industry specific departments.

We look forward to reviewing your router-less architecture.

Mr. Benanamen
ABC Company


<Out of Character>

The aforementioned is a real application I have already written for exactly such a company so I have real life basis and experience of the needs, obstacles and problem solutions to such an organization.

</Out of Character>
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 523
  • Karma: +90/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #4 on: 7 Nov 2020, 02:36:32 pm »
Around two thirds of that I'd have in completely separate applications from the web presence, with inter-communications. I would NOT use web technologies for at least half of it. At all.

Shoe-horning it all into a single web technology stack is just asking for needless complexity, possible security issues, and painfully bloated hard to maintain codebases.

Again, one size fits all fits nobody. Many of those things -- warehouse management, HR, Building maintennance, and so forth have NO business using web technologies or being integrated into one giant "application". At all. Or at least, sure as shine-ola having NOTHING to do with the public facing website! NONE of that really seems to have a damned thing to do with what I talk about with website construction or how I would go about things. We're LIGHT YEARS apart on this. I WOULD NOT have the main website or its code have anything to do with more than around two thirds of that list!

It sounds like an unrealistic idealistic nonsensical request by people who don't know what to actually ask for, or how any of this stuff should be managed.

It also makes it sound like a lot of the "management" isn't doing their jobs actually managing things. A problem I come across a lot when talking the efficiency side of things.

Basically you've got feature creep lumping together things that should be entirely separate entities and codebases. Again, the proverbial carpenter with a hammer to whom everything looks like a nail.

EXACTLY the type of messes I'm usually called in to rip apart and coach them on rebuilding from the ground up.
« Last Edit: 7 Nov 2020, 02:43:02 pm by Jason Knight »
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

benanamen

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +6/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #5 on: 7 Nov 2020, 02:42:51 pm »
I am seeing plenty of feedback but not a lick of code showing how you would make a routerless site/app/whatever you want to call it. Hmmm.    :-\
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 523
  • Karma: +90/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #6 on: 7 Nov 2020, 02:47:40 pm »
I am seeing plenty of feedback but not a lick of code showing how you would make a routerless site/app/whatever you want to call it. Hmmm.    :-\
That's because AS I ALREADY FLIPPING SAID, I won't be back at my workstation with time free to do that until later. Likely not even until monday.

As it is I'm sitting here replying to forum threads whilst stuffing my face, then it's right back to Installing Win10 and all the client's software on three separate 5800X builds. With 2070 supers in them because it seems to be the only blasted video card for sale right now...

I might get something up for code sooner if insomnia sets in, but for now I'm planning for such a post Monday. AND AGAIN part of why I want to dedicate a day to it is so I can simplify and over-document to explain the how/what/why/where of it. I tend to take a few code shortcuts on deployment that if we're going to break down how I do things, it might be better if it were more... verbose.

Besides, I've learned better than to try and code on the useless crap laptop's have for keyboards. Model M FTMFW.

But then the way people react to my "wall of text" posts that take me less time to make than it does to eat an egg roll...
« Last Edit: 7 Nov 2020, 02:51:47 pm by Jason Knight »
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

benanamen

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +6/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #7 on: 7 Nov 2020, 03:18:47 pm »
Sounds good. Looking forward to talking about it.
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 523
  • Karma: +90/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #8 on: 9 Nov 2020, 09:31:19 am »
Alright, I've got 'till 11AM EST to work on tossing together a demo. Coding starts when this post goes up.

I want to do this "from scratch" to double-check and modernize my own methodologies. This way we have a simple clean slate without any left-over "Cruft" from other projects.

When doing this sort of thing I always like to work in the following order:

1. What's the content? I always say "content first" not just for design, but for the back end as well. Certainly things can change, but if you don't know what the data is or what you're going to serve client-side, how the blazes is one making rational choices about the back end?

This is where again, frameworks are a steaming pile of epic /fail/. People expect them to magically create their data handling / structure for them.

In this case it's easy, we're building a poor man's to glue together a template system to static pages. BUT, we're going to want it extensible so functionality can be easily added, as well as laying the ground work if one wants to expand it to use a database.

2. That content and functionality DICTATES directory structure!

For now I'm going with:

/ -- index.php, ini files

/actions -- location of each of our user calls

/actions/actionName -- a directory holding all files specific to that action

/actions/static -- the static page server, also our default action.

/actions/static/pages -- the static page content to be served.

/extras -- small sections usually plugged into "sidebars". We will code support for up to two sidebars.

/fragments -- smaller user configurable "pieces" such as the footer content, the http error handler, and so forth.

/images/ -- content images

/modals -- the content of any modal dialogs

/template/templateName -- our various part.template.php and CSS

/template/templateName/images -- presentational / template images

This is an improvement on my "classic" methodology in that I'm moving all files relating to a specific action into its own subdirectory. Laughably my old structure of putting the handlers directly into /actions stems from my old Borland Paradox codebases.

3. Code the common library functions and objects commonly needed on all pages. In this case we'll need a few string cleaners, a Request static object, a Settings static object, and a few DEFINE.

4. Write the index.php to get a general feel for what the various static sub-files need to handle.

5. Write the common template so that we have something to wrap our output in. I have a WIP generic outer template from another project that should fit the bill with minimal modifications. I actually made it for testing CSS variables.

6. Write the http error handlerm with no "actions" coded we can test this as a 404.

7. Write the /action/static (default) behavior to serve the appropriate page content

8. Write a static home page

9. Implement a dummy contact form (no send logic) to test a second action

10. Make a second "Static" page that's semi-dynamic (needs a couple of our Settings or define). Typically needed for images if system is not installed in root. Since my current modal technique doesn't like <base>

Now, for storing config data I'm going to use .ini files. I like them because PHP has a perfectly good parser built in, and you can do this:

Code: [Select]
; <?php die('hacking attempt detected';);

At the start of them so that SHOULD our redirects fail and someone tries to access them, it doesn't output our config info.

Thankfully ini allows for two-dimensional values, so an example default.ini.php (lifted straight off an existing page of mine) would go:

Code: [Select]
; <?php die(); // prevent direct calls just in case

; *** DO NOT MODIFY *** override in user.ini.php instead.

siteTitle "default template"
h1Content "Default Template"
template "default"
currentPage "home"

[link]
favicon[rel] = "shortcut icon"
favicon[href] = favicon.ico

[style]
vars.screen.css "screen,projection,tv"
layout.screen.css "screen,projection,tv"

See that on favicon? Noice.

Alright, let's start the clock. I've got an hour and a half until I have to stop working on this and zoom a potential client.
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 523
  • Karma: +90/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #9 on: 9 Nov 2020, 09:42:53 am »
Gonna write down some more notes as I go.

There will be two standard types of "content" includes declared by filename.

.static -- static content to be sent direct to the output buffer via readFile

.content.php -- contains an action_content() to be called by index.php

The module and extras systems will also have similar functionality, though their function name should be along the lines of:

moduleName_run($data);

Which we can use the immediate var function trick to invoke.

($moduleName . '_run')($data);

That way we can dynamically add relatively safely.

Oh, and when possible no .php files other than index.php should output ANYTHING if called directly. There may be a few exceptions, but that's the ideal.
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 523
  • Karma: +90/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #10 on: 9 Nov 2020, 10:05:36 am »
I'll be posting .phpSource here:

https://cutcodedown.com/for_others/squire3/sources/

/libs/common.lib.php, index.php, the errorHandler fragment, and both the .ini files complete.

... and template sliced up nice and easy, but that's mostly experience with my techniques.
« Last Edit: 9 Nov 2020, 10:09:22 am by Jason Knight »
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 523
  • Karma: +90/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #11 on: 9 Nov 2020, 10:17:42 am »
... and done.

Live copy here:
https://cutcodedown.com/for_others/squire3/live

full archive here:
https://cutcodedown.com/for_others/squire3/squire3.rar

I'll use what little time I have left before the client meeting to start doing some proper documentation of the how/what/why of it.
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

benanamen

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +6/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #12 on: 9 Nov 2020, 12:50:43 pm »
Mr. Jason.

Thank you for taking the time to provide a demo for our discussions.

On first view of the live example, we find it to be very clean. The Dark Mode option is very nice as well as the header pin and the contact modal. The browser source is also nicely formatted. While the W3C Validator does show some minor "errors", we are aware of your previous comments on some of the ones presented. It is not important to our discussions. Also, just to note, there is a formatting issue of the menu on mobile. Again, not important for this discussion.

I will post back after getting familiar with the source code.
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 523
  • Karma: +90/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #13 on: 9 Nov 2020, 01:21:34 pm »
Heh, yeah... the errors can bite me; and I was particularly dismayed that now the ONLY reason for x-ua to exist is now considered invalid, whilst the pointless garbage use for it is the only valid one.

The default behavior for X-UA should be edge, or shouldn't matter if your HTML is well formed. The only reason to use X-UA is to tell browsers to use OLDER versions of their renderer, not the latest! As if telling IE 8 to use "edge" is going to make it be anything more than IE8? Right, keep sucking down that tainted flavor-aid folks!

On a meta, something that is NONE of the HTML specification's business. I thought their going full gungan over media targets was bad, but that's just above and beyond. It's halfwit bullshit like that which makes W3C validation and the HTML 5 specification useless crap. They won't be happy until they undo EVERYTHING 4 Strict was trying to accomplish.

Open letter to the W3C:



Dear W3C,

When your validator now says the following things?

"A meta element with an http-equiv attribute whose value is X-UA-Compatible must have a content attribute with the value IE=edge."

F*** you.

"Bad value screen,projection,tv for attribute media on element link: The media projection has been deprecated"

Double f*** you.

"Attribute aria-hidden is unnecessary for elements that have attribute hidden."

Quadruple f*** you.

-- Sincerely, people with brains.



The laugh being this was valid HTML 5 a year ago, but with no version tracking in the document -- f*** the W3C for that bit of stupid too -- what's valid HTML 5 today can be invalid HTML 5 tomorrow. AGAIN further defeating the point of their dip**** validation and f***wit "living document" IDIOCY!

The "stupid" to get full compliance with today's HTML 5 (as opposed to last year's HTML 5, or the year before that's HTML 5) is below my pay grade. More so with the number of UA's that end up neglected if you follow their dip**** ARBITRARY rules.

HTML 5, it's on the way to becoming the new HTML 3.2.

Also yes, there is ZERO code present for the mobile menu. none, I haven't written that for said template yet, as I said the template side of things is an incomplete WIP I just slapped in there as a placeholder.
« Last Edit: 9 Nov 2020, 01:29:45 pm by Jason Knight »
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

benanamen

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +6/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #14 on: 9 Nov 2020, 01:25:28 pm »
While not relative to the discussion, the following should be noted.

EDIT: I just added "static" to the get method in common.lib.php line 124

Before: public function get($name, $section = false)
After: public static function get($name, $section = false)

By the way, if we were doing this on Github we could collaborate/update/propose/sync code/ etc, etc much better. I am aware of your thoughts on Github, but it does add a lot of benefit for what we are doing. If you like, I can put the code on a repo, but since it is your codebase, it would be better if you did it.
 


Code: [Select]
Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\index.php on line 55

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\libs\common.lib.php on line 78

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 18

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 20

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 222

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 222

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 38

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 60

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 61

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 84

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 91

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 93

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 154

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 156

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 157

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 181

Deprecated:  Non-static method Settings::get() should not be called statically in C:\laragon\www\squire3\templates\default\common.template.php on line 182
« Last Edit: 9 Nov 2020, 01:58:25 pm by benanamen »
To save time, let's just assume I am never wrong.

 

Advertisement