Didn't describe things quite right; wro4j works as a filter at runtime, but still assumes a static description of what needs combining/transforming/compiling/etc. In a Tapestry application, that all needs to be figured out dynamically, on the fly, based on the what's in the framework, application, and 3rd party libraries.
On Thu, Dec 8, 2011 at 2:33 PM, Alex Objelean <alex.objel...@gmail.com> wrote: > Actually it is geared for runtime solution as well. There is no difference in > using less or coffeeScript (or sass, or any other available processors) for > a runtime or build time solution. > > Cheers, > Alex > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/smarter-css-tp5051068p5060273.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
