Stephen Colebourne wrote:
My main concern would be whether framework providers would be convinced to use it. Does it provide enough benefit to a framework provider over just writing the code yourself? Would existing frameworks switch to it?
As I said in my answer to James, frameworks that already have such a feature may be reluctant to switching to this stuff because of code compatibility problems. But there are a number of other projects where external files don't have as much importance as they have in Hivemind/Tapestry and Cocoon where the problem is simply ignored or poorly considered because it is not vital to the project.
This is one of the main purposes of this proposal: provide an easy solution to this problem, so that ignoring it is no more an option. The other purpose being that, through and increased cross-project consistency, it's easier to deal with external files handled by third-party libraries that use this common location stuff, thus avoiding (or at least limiting) the need to parse error messages to rebuild the location information.
Also, [location] made me think of locations in the world, so maybe commons-exception would be clearer.
Hmm... it's not only about exceptions, but more about locations in files (config, template, properties, whatever), and attaching these locations to objects that were created from these files. Locations can then be used in log messages, exceptions, and why not specialized debuggers (I'm about to write one for Cocoon).
So, what about "object-location" or the shorter "objloc"? Sylvain -- Sylvain Wallez Anyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
