That's a great point. In the past I created a class to serve as a tag parser that could pull documents apart and evaluate script or LS fragments ala JSP's in LS. What Jake has here is just what Axel says - good tool for the specific job in mind.
What we are talking about is two different patterns. HTML that is meant to be maintainable as a requirement of the project necessarily should have a framework behind it so that frequent expected changes can be accommodated.
Jake's example of the calendar from the other day is actually a component build, where having small reusable modules like this baked in makes the code more portable and tamper proof. No config files / documents needed. Using a framework would make the packaged drop-in module less packaged and drop-in.
As someone I know says - horses for courses... :-)
@ Bob M
That's a great point. In the past I created a class to serve as a tag parser that could pull documents apart and evaluate script or LS fragments ala JSP's in LS. What Jake has here is just what Axel says - good tool for the specific job in mind.
What we are talking about is two different patterns. HTML that is meant to be maintainable as a requirement of the project necessarily should have a framework behind it so that frequent expected changes can be accommodated.
Jake's example of the calendar from the other day is actually a component build, where having small reusable modules like this baked in makes the code more portable and tamper proof. No config files / documents needed. Using a framework would make the packaged drop-in module less packaged and drop-in.
As someone I know says - horses for courses... :-)