"The idea is that Controls could be decorated with custom JS/CSS without having to override them. "
I would not even ask an opinion on this: this is really great! Thanks for the good work. Malcolm Edgar-2 wrote: > > On Tue, Mar 3, 2009 at 8:30 AM, Bob Schellink <[email protected]> wrote: > >> Hi all, >> >> I'm starting to sound like a broken record but would again like to raise >> the issue regarding utility classes for Javascript and CSS resources. >> >> An alternative solution was mentioned by exposing static helper methods >> to >> create the imports. >> >> However I think utility classes is more flexible in the long run >> especially >> for Ajax. >> >> Btw here's a list of use cases the utility classes should address: >> >> # JavaScript and CSS not restricted to a single line and can be loaded >> from a Velocity template. >> >> # Uniqueness of a resource can be implemented with #equals and >> #hashcode. A JavaScript Import could be unique based on its HTML src >> attribute, while inline JavaScript could be unique based on an HTML >> id attribute or even its content. >> >> # Apply an application wide version indicator to resources which helps >> with browser caching >> >> # Render conditional comments for IE >> >> # Surround JavaScript in CDATA tags (this is useful when doing Ajax) >> >> >> Another change I've been chewing on (I should probably open a separate >> thread for this, but will mention it briefly) is to replace the method >> "public String getHtmlImports" with "public List getHtmlImports()". OK >> "replace" is a bit strong, deprecate is more likely. >> >> The idea is that Controls could be decorated with custom JS/CSS without >> having to override them. >> > > +1 > > >> >> >> What do you think? >> >> kind regards >> >> bob >> >> > > -- View this message in context: http://n2.nabble.com/Resource-utility-classes-tp2411821p2427361.html Sent from the click-development mailing list archive at Nabble.com.
