HTML Helper

[lonnieezell]

Port the current HTML helper over from CI3, with the following exceptions:

• remove the deprecated methods
• remove header() and meta() methods.

Which primarily leaves us with the list building tools. Should this be combined with something else?

Maybe add:

• media method to help embed media objects.
• table_headers (see CakePHP)
• table_cells (see CakePHP)

This probably makes sense to implement as a class with static methods.

Development Checklist:

• Component(s)
• ... with PHPdocs
• Unit testing
• ... with >80% coverage
• User guide updated
• Classmap integration?
• Securely signed commits
• Conforms to style guide

[prezire]

• Best to include script_tag() along with tokenizers. See Laravel's Elixir https://laravel.com/docs/5.2/elixir#versioning-and-cache-busting
• It would also be good to allow both script_tag() and link_tag() to be able to process lists like script_tag($scriptUrls, true); wherein the 2nd param generates and appends random cache-busting token if true, uses a value from config if false, nothing if nulland custom value if string or number
• The static method goes outside the formatting of other helpers. Probably good to make it procedural as decided

[lonnieezell]

• Best to include script_tag() along with tokenizers. See Laravel's Elixir https://laravel.com/docs/5.2/elixir#versioning-and-cache-busting

If we do that, we also need a css_tag function with the same feature. The problem I see with that, though, is that it then requires a controller to interpret that cache-busting filename and return the correct asset. Which is definitely heavier then we want here. I'm all for the feature, but don't think it fits the CodeIgniter way.

That said - I could potentially see it as a before/after filter that checks the file datetime and auto-creates tag busters on the way out, and interprets them on the way in... but that sounds pretty involved also.

Probably best to leave for whatever front-end solution people use, like gulp, which Elixir is a front-end for.

• The static method goes outside the formatting of other helpers. Probably good to make it procedural as decided

The nice thing about writing the framework is it doesn't have to be a helper anymore, we can always call it a library and it's all good. :)

Seriously, though, my thought was that this and the Form builder would both be static classes, making it so they didn't have to be autoloaded, but have since recently realized that would be ugly as all get out, since you'd have to use the full namespace every time. So, yes, back to procedural.

[prezire]

All good. Best to leave these as front-end and procedural.

However, if there are plans moving from procedural to OOP some time in the future for helpers, perhaps $this->classmap[] structure under ./system/Config/AutoloadConfig.php can help prevent typing lengthy qualified namespaces.

There's no need to create a separate css_tag() since link_tag() has rel and type attributes.

[prezire]

I can work on this.

[lonnieezell]

Sounds good. I'll mark it as in progress. Thanks!

[prezire]

Thanks. I wouldn't recommend adding convenience to table items such as header and cells. It only adds complications and confusion instead of making things simple. Imagine adding attributes such as class, id or data http://icecream.me/3dadb3eeae7e88309d7bbedbe50345b3 and http://icecream.me/c6bc70d58ae4f159e6b27515e8e5f0d4.