On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
+1. But I can see Ed's point that doing something like this is still better than doing nothing.
I don't think this solution is at all sufficient, though ... at least if you store it inside the jar file for a particular component library. As a developer of a third party component library yourselves, what value should MyFaces pick for the Tomahawk components? What happens to the build process of every application using those components if the value is changed later? What happens if a library that Tomahawk might depend on changes *their* value so that it's suddenly higher than the Tomahawk one, instead of lower?
Some sort of dependency declaration is going to be necessary for solving this problem completely. There's precedent in the way that a JAR file can declare dependencies on other JARs in it's MANIFEST.MF file ... something like that should be explored here as well.
If your development environment requires you to restart the entire container on simple changes, you need a new development environment :-). That's not to say we should still work on reducing the number of times you have to redeploy the application you're currently working on -- indeed, the fact that JSP pages recompile themselves on demand shows that at least portions of the underlying problem were solved ... five years ago !
Craig
You are right - simple naming rules are great! But RoRs naming rules
try to make it simpler for the user - this one makes it more complex,
as he has to take care of this ordering.
The users won't want to rename the libs to make this work...
+1. But I can see Ed's point that doing something like this is still better than doing nothing.
I have carefully thought about it, and I think we will end up with the
need for a "priority", just like the Z-INDEX in CSS. With all its
problems, with all its advantages.
I don't think this solution is at all sufficient, though ... at least if you store it inside the jar file for a particular component library. As a developer of a third party component library yourselves, what value should MyFaces pick for the Tomahawk components? What happens to the build process of every application using those components if the value is changed later? What happens if a library that Tomahawk might depend on changes *their* value so that it's suddenly higher than the Tomahawk one, instead of lower?
@Mike: customizing the comparator doesn't help anything - you finally
land at the problem again that every lib can provide it's comparator -
which one is wrapping which, which one takes precedence?
Some sort of dependency declaration is going to be necessary for solving this problem completely. There's precedent in the way that a JAR file can declare dependencies on other JARs in it's MANIFEST.MF file ... something like that should be explored here as well.
regards,
Martin
P.S.: apart from this, I think the real advantage of RoR is that you
don't have to restart your ServletContainer on a small change...
If your development environment requires you to restart the entire container on simple changes, you need a new development environment :-). That's not to say we should still work on reducing the number of times you have to redeploy the application you're currently working on -- indeed, the fact that JSP pages recompile themselves on demand shows that at least portions of the underlying problem were solved ... five years ago !
Craig
