@Mathewlenning Github tell us This branch has conflicts that must be resolved.

This is an RFC style PR. It doesn't need to be perfect.

@zero-24

I saw that. Not sure what the cause is. Since this is just an example to show how #7948 works, it isn't that important.

Sincerely,
Mathew Lenning

P.S. This message was sent via iPhone, so please forgive any errors

On Sep 28, 2015, at 11:00 PM, zero-24 notifications@github.com wrote:

@Mathewlenning Github tell us This branch has conflicts that must be resolved.

―
Reply to this email directly or view it on GitHub.

Just comparing the current layout file and the one you propose here as an example.

Orig - easy to understand by a NON developer aka a front end developer/designer
New - havent got a clue what it is doing

So where is the benefit of rewriting the layout so that it can not be understood by its intended user

Lol =^D O.K.

Sincerely,
Mathew Lenning

P.S. This message was sent via iPhone, so please forgive any errors

On Oct 1, 2015, at 7:25 PM, Brian Teeman notifications@github.com wrote:

Just comparing the current layout file and the one you propose here as an example.

Orig - easy to understand by a NON developer aka a front end developer/designer
New - havent got a clue what it is doing

So where is the benefit of rewriting the layout so that it can not be understood by its intended user

―
Reply to this email directly or view it on GitHub.

Really Brian, why not just say "Hey I don't like this." You don't have to play dumb. You're entitled to your opinion mate.

Sincerely,
Mathew Lenning

P.S. This message was sent via iPhone, so please forgive any errors

On Oct 1, 2015, at 7:25 PM, Brian Teeman notifications@github.com wrote:

Just comparing the current layout file and the one you propose here as an example.

Orig - easy to understand by a NON developer aka a front end developer/designer
New - havent got a clue what it is doing

So where is the benefit of rewriting the layout so that it can not be understood by its intended user

―
Reply to this email directly or view it on GitHub.

You made a PR asking for comments. I looked at the code and with my
skillset I commented

Nothing to do with "liking" anything

On 1 October 2015 at 11:30, Mathew Lenning notifications@github.com wrote:

Really Brian, why not just say "Hey I don't like this." You don't have to
play dumb. You're entitled to your opinion mate.

Sincerely,
Mathew Lenning

P.S. This message was sent via iPhone, so please forgive any errors

On Oct 1, 2015, at 7:25 PM, Brian Teeman notifications@github.com
wrote:

Just comparing the current layout file and the one you propose here as
an example.

Orig - easy to understand by a NON developer aka a front end
developer/designer
New - havent got a clue what it is doing

So where is the benefit of rewriting the layout so that it can not be
understood by its intended user

―
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#7969 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

It is obvious that Joomla will always be second best (or worst) until those in the inner circle start looking at potential and using their imagination.

Sincerely,
Mathew Lenning

P.S. This message was sent via iPhone, so please forgive any errors

On Oct 1, 2015, at 7:25 PM, Brian Teeman notifications@github.com wrote:

Just comparing the current layout file and the one you propose here as an example.

Orig - easy to understand by a NON developer aka a front end developer/designer
New - havent got a clue what it is doing

So where is the benefit of rewriting the layout so that it can not be understood by its intended user

―
Reply to this email directly or view it on GitHub.

Brian I've seen your comments on other PRs, so I know this is a case of selective skill set. Just tell everyone you don't like it and be done with it. I hate politics and BS

Sincerely,
Mathew Lenning

P.S. This message was sent via iPhone, so please forgive any errors

On Oct 1, 2015, at 7:32 PM, Brian Teeman notifications@github.com wrote:

You made a PR asking for comments. I looked at the code and with my
skillset I commented

Nothing to do with "liking" anything

On 1 October 2015 at 11:30, Mathew Lenning notifications@github.com wrote:

Really Brian, why not just say "Hey I don't like this." You don't have to
play dumb. You're entitled to your opinion mate.

Sincerely,
Mathew Lenning

P.S. This message was sent via iPhone, so please forgive any errors

On Oct 1, 2015, at 7:25 PM, Brian Teeman notifications@github.com
wrote:

Just comparing the current layout file and the one you propose here as
an example.

Orig - easy to understand by a NON developer aka a front end
developer/designer
New - havent got a clue what it is doing

So where is the benefit of rewriting the layout so that it can not be
understood by its intended user

―
Reply to this email directly or view it on GitHub.

―
Reply to this email directly or view it on GitHub
#7969 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
―
Reply to this email directly or view it on GitHub.

Ask any developer what my skillset is

So, you replaced 10 lines of perfectly readable HTML code which a front-end developer can easily figure out how to override with 12 lines of stiff PHP code that's impossible at first glance even for a developer to understand what kind of DOM it produces. At the same time you did NOT solve the problem of catering for different CSS frameworks (e.g. BS3 vs BS2 or, worse, something entirely different like Zurb). If anything, you made it far worse. Let's see what are the alternatives we have:

• Current situation. The template developer needs to override JHtml elements. This is hard to do because they are PHP classes which need to be mass preloaded for the autoloader not to use the originals. And since they carry logic which may change from one Joomla! version to another they are very likely to break Joomla!. At least they have bits of HTML that a front-end developer can understand and modify with minimal trial and error.

• Your PR. The worst possible scenario. The template developer needs to override JHtml elements. This is hard to do because they are PHP classes which need to be mass preloaded for the autoloader not to use the originals. And since they carry logic which may change from one Joomla! version to another they are very likely to break Joomla!. They don't even have HTML that a front-end developer can understand. Instead, they have a stiff PHP syntax to create the DOM. So the developer must understand both front-end development AND back-end development AND keep the DOM in her head while she's trying to make the override.

• Using JLayouts which, by the way, is what we decided yesterday to use for Joomla! 4. The actual JHtml class needs not be touched. The JLayout file, which is just an HTML template with interspersed echo's and simple if-blocks (like our view templates), can be overridden in the template. Using the SAME skillset front-end developers have been using since 2007 to write template overrides.

So between a hard, impossible and dead easy solution you propose that we should be using the impossible solution instead of the dead easy solution. Even worse, this PR tries to provide a solution for a problem we don't have (how to output HTML), therefore creating a new, massive problem that makes Joomla! impossible to use by anyone who's not a back-end developer, i.e. pretty much our entire existing user base.

This has a solid -1 from me. There is no possible universe where this... monstrosity is even an alternative to writing HTML, let alone a good one.

I'm sorry if I hurt your feeling. Still waiting for you to show me where the Business logic is.

Anyway thanks for the input, I'm sure a lot of people are exited to here J4 will be the same as the last 7 years.

Sincerely,
Mathew Lenning

P.S. This message was sent via iPhone, so please forgive any errors

On Oct 1, 2015, at 8:33 PM, Nicholas K. Dionysopoulos notifications@github.com wrote:

So, you replaced 10 lines of perfectly readable HTML code which a front-end developer can easily figure out how to override with 12 lines of stiff PHP code that's impossible at first glance even for a developer to understand what kind of DOM it produces. At the same time you did NOT solve the problem of catering for different CSS frameworks (e.g. BS3 vs BS2 or, worse, something entirely different like Zurb). If anything, you made it far worse. Let's see what are the alternatives we have:

Current situation. The template developer needs to override JHtml elements. This is hard to do because they are PHP classes which need to be mass preloaded for the autoloader not to use the originals. And since they carry logic which may change from one Joomla! version to another they are very likely to break Joomla!. At least they have bits of HTML that a front-end developer can understand and modify with minimal trial and error.

Your PR. The worst possible scenario. The template developer needs to override JHtml elements. This is hard to do because they are PHP classes which need to be mass preloaded for the autoloader not to use the originals. And since they carry logic which may change from one Joomla! version to another they are very likely to break Joomla!. They don't even have HTML that a front-end developer can understand. Instead, they have a stiff PHP syntax to create the DOM. So the developer must understand both front-end development AND back-end development AND keep the DOM in her head while she's trying to make the override.

Using JLayouts which, by the way, is what we decided yesterday to use for Joomla! 4. The actual JHtml class needs not be touched. The JLayout file, which is just an HTML template with interspersed echo's and simple if-blocks (like our view templates), can be overridden in the template. Using the SAME skillset front-end developers have been using since 2007 to write template overrides.

So between a hard, impossible and dead easy solution you propose that we should be using the impossible solution instead of the dead easy solution. Even worse, this PR tries to provide a solution for a problem we don't have (how to output HTML), therefore creating a new, massive problem that makes Joomla! impossible to use by anyone who's not a back-end developer, i.e. pretty much our entire existing user base.

This has a solid -1 from me. There is no possible universe where this... monstrosity is even an alternative to writing HTML, let alone a good one.

―
Reply to this email directly or view it on GitHub.

Sorry I meant the same thing we've been doing since 2007.

Sincerely,
Mathew Lenning

P.S. This message was sent via iPhone, so please forgive any errors

On Oct 1, 2015, at 8:33 PM, Nicholas K. Dionysopoulos notifications@github.com wrote:

So, you replaced 10 lines of perfectly readable HTML code which a front-end developer can easily figure out how to override with 12 lines of stiff PHP code that's impossible at first glance even for a developer to understand what kind of DOM it produces. At the same time you did NOT solve the problem of catering for different CSS frameworks (e.g. BS3 vs BS2 or, worse, something entirely different like Zurb). If anything, you made it far worse. Let's see what are the alternatives we have:

Current situation. The template developer needs to override JHtml elements. This is hard to do because they are PHP classes which need to be mass preloaded for the autoloader not to use the originals. And since they carry logic which may change from one Joomla! version to another they are very likely to break Joomla!. At least they have bits of HTML that a front-end developer can understand and modify with minimal trial and error.

Your PR. The worst possible scenario. The template developer needs to override JHtml elements. This is hard to do because they are PHP classes which need to be mass preloaded for the autoloader not to use the originals. And since they carry logic which may change from one Joomla! version to another they are very likely to break Joomla!. They don't even have HTML that a front-end developer can understand. Instead, they have a stiff PHP syntax to create the DOM. So the developer must understand both front-end development AND back-end development AND keep the DOM in her head while she's trying to make the override.

Using JLayouts which, by the way, is what we decided yesterday to use for Joomla! 4. The actual JHtml class needs not be touched. The JLayout file, which is just an HTML template with interspersed echo's and simple if-blocks (like our view templates), can be overridden in the template. Using the SAME skillset front-end developers have been using since 2007 to write template overrides.

So between a hard, impossible and dead easy solution you propose that we should be using the impossible solution instead of the dead easy solution. Even worse, this PR tries to provide a solution for a problem we don't have (how to output HTML), therefore creating a new, massive problem that makes Joomla! impossible to use by anyone who's not a back-end developer, i.e. pretty much our entire existing user base.

This has a solid -1 from me. There is no possible universe where this... monstrosity is even an alternative to writing HTML, let alone a good one.

―
Reply to this email directly or view it on GitHub.

Just one last note before I'm off to bed. This example is just to illustrate how the class works.

And although I don't like repeating myself. Since you were obviously to busy being yourself, to hear what I was saying on Twitter, I'll make an exception this time.

Of the three options you gave us, none of them are acceptable to me. That's because this little class is part of a bigger idea and the key to a fourth option.

The forth option offers the opportunity to COMPLETELY separate markup from PHP and lets front-end developers work in XHTML which is a W3C standard.

In this option you can switch between framework without copy and paste overrides, because with this option the business logic really is separate from the presentation layer. And changing an XHTML file isn't going to be a BC issue.

I know, I know. In your universe this option doesn't exist. But should Joomla be limited just to your universe?

That's all I have to say. Continue on fearless leader. You've gotten us this far right.

Sincerely,
Mathew Lenning

P.S. This message was sent via iPhone, so please forgive any errors

On Oct 1, 2015, at 8:33 PM, Nicholas K. Dionysopoulos notifications@github.com wrote:

So, you replaced 10 lines of perfectly readable HTML code which a front-end developer can easily figure out how to override with 12 lines of stiff PHP code that's impossible at first glance even for a developer to understand what kind of DOM it produces. At the same time you did NOT solve the problem of catering for different CSS frameworks (e.g. BS3 vs BS2 or, worse, something entirely different like Zurb). If anything, you made it far worse. Let's see what are the alternatives we have:

Current situation. The template developer needs to override JHtml elements. This is hard to do because they are PHP classes which need to be mass preloaded for the autoloader not to use the originals. And since they carry logic which may change from one Joomla! version to another they are very likely to break Joomla!. At least they have bits of HTML that a front-end developer can understand and modify with minimal trial and error.

Your PR. The worst possible scenario. The template developer needs to override JHtml elements. This is hard to do because they are PHP classes which need to be mass preloaded for the autoloader not to use the originals. And since they carry logic which may change from one Joomla! version to another they are very likely to break Joomla!. They don't even have HTML that a front-end developer can understand. Instead, they have a stiff PHP syntax to create the DOM. So the developer must understand both front-end development AND back-end development AND keep the DOM in her head while she's trying to make the override.

Using JLayouts which, by the way, is what we decided yesterday to use for Joomla! 4. The actual JHtml class needs not be touched. The JLayout file, which is just an HTML template with interspersed echo's and simple if-blocks (like our view templates), can be overridden in the template. Using the SAME skillset front-end developers have been using since 2007 to write template overrides.

So between a hard, impossible and dead easy solution you propose that we should be using the impossible solution instead of the dead easy solution. Even worse, this PR tries to provide a solution for a problem we don't have (how to output HTML), therefore creating a new, massive problem that makes Joomla! impossible to use by anyone who's not a back-end developer, i.e. pretty much our entire existing user base.

This has a solid -1 from me. There is no possible universe where this... monstrosity is even an alternative to writing HTML, let alone a good one.

―
Reply to this email directly or view it on GitHub.

When I read your code when you sent me the link on Twitter I misread it. I thought you were simply misguided and did the same thing as JHtml was doing since 2004 (remember, it was added back in Mambo...), outputting hardcoded and unoverridable HTML from a PHP class.

Sorry, I was wrong. You managed to find an even WORSE way to make JHtml tick. Your unprovoked attack to common sense replaced the hardcoded HTML with a DOM builder that screams "I am trying to write jQuery in PHP". So instead of a class outputting hardcoded HTML code we have a class using a DOM builder to output hardcoded HTML code. Congratulations, you managed to take a bad solution and turn the dial of unusability all the way to 11. * slow clap *

Meanwhile, since 2012 (NOT 2007, you ought to know) we have JLayouts. The problem is that JLayouts are currently NOT implemented across the entire core. While we have JLayouts for some bits of JHtmlBootstrap (https://github.com/joomla/joomla-cms/tree/staging/layouts/libraries/cms/html/bootstrap) we don't have that for pretty much everything else. So, while a template developer CAN override JLayouts for tabs and tabsets they can't do the same for grid management. And since the same non-use applies to JForm we have a sparsely applied solution which undermines its power. The goal in Joomla! 4 is to have all JForm and JHtml use JLayouts. Because they can be easily overridden and solve the problem about different DOM requirements for each CSS framework.

So, as anyone who actually knows how Joomla! works can tell you, we are NOT doing the same thing as we had since 2007. We are trying to apply a solution. What YOU are trying to do is take the bad solution we had since 2004 (NOT 2007) and make it FAR WORSE in terms of being overridable, understandable or even slightly usable.

And sorry for telling you, but as soon as you have a DOM builder class any solution you base off it is unusable by front-end developers. You have seen the (largely non-existent) quality and skillset of back-end developers employed by template clubs. Do you honestly believe that these people can take a DOM builder and create a template that doesn't break with every subminor Joomla! release? Or that our DIY users, still a large part of our user base, who only barely understand enough HTML and CSS to make their sites look passable will be able to use your convoluted DOM builder?

In which possible universe writing $something->addNode('ul') is easier than writing <ul>?! Have you ever tried teaching non-coders how to do basic things, like if-blocks or even variable assignments? If you did you'd have known that having them deal with OOP, even at this kindergarten level, is outright IMPOSSIBLE. They will simply abandon Joomla! for WordPress. So, yeah, I'm pretty sure that if we were to adopt your non-solution all our users would be extremely happy to hear that Joomla! will now require understanding OOP to output HTML for a different CSS framework.

Finally, you say on Twitter that it's not about ego but progress. Yet you vehemently attack everyone who's not drinking your kool aid. Well, listen up. Progress is happening. And it's not about ego. It's about several people sitting together and coming up with mutually acceptable solutions. If someone is a minority of one (as I have been in some decisions) they shut up and accept the majority's opinion. If you want to put your proposal up for voting in the J! 4 architecture group be my guest. Spare me your pseudo-macho attitude and put this up for voting if you dare. You already have a -1 from me.

Over and out. I unsubscribe from this thread too; don't bother replying.

I add my 2 cents
I agree with @brianteeman .. it more difficult for non programer to read that code ... I mean people, who just write HTML markup and do styling ....
And I think that JHtmlElement can be useful in some Helper class ... but we definitely should not write whole layout using this

@Fedik I agree. These examples were just to show how the interface works.

Ideally I would like to keep the layouts in .xhtml files and turn the JLayouts class into something more robust. Right now it just selectively loads files and returns the buffer contents of procedural templates.