Re[2]: Barracuda: case-insensitive event names?

Hello James,

See comments below...

Friday, December 13, 2002, 1:22:37 PM, you wrote:

JG> It seems this might be easily implemented on the servlet container too.
JG> Maybe look into that before putting in Barracuda.  That way you could
JG> use it in other projects too.

Too late, already in Barracuda (thanks to Christian!). :-)

But seriously, I'm not sure exactly how this would be implemented in
the container config or via a servlet filter because the event name has to be matched with existing registered events which you
don't really have access to unless you query the event model.  I
suppose you might be able to do this from a servlet filter, but I'm
not sure why you wouldn't just support it in Barracuda unless there
are some serious consequences by doing it?

JG> Generally speaking, I have no objections to case-insensitivity for
JG> things like this.  If you've got two events:

JG> MyEventFoo1.event
JG> MyeventFoo1.event

JG> that are supposed to map to different controllers, you're just _asking_
JG> for trouble.

I agree that this might be some trouble.  However, I'd say that this
is more the developers fault for naming events like this.
Additionally, the way events are auto-generated via the Events Ant
taskdef, all events go into the same package.  As such, names such as
MyEventFoo1 and MyeventFoo1 wouldn't really be possible, would they?
Or would this just be the case on a Windows system which doesn't
enforce case-sensitive files?  In the Windows case,
MyEventFoo1.java would be overwritten by MyeventFoo1.java, although
the original name "MyEventFoo1.java" would probably be preserved
causing a compile problem because Java *is* case-sensitive and the class
name in the file would be "MyeventFoo1" where the file name would be
"MyFooEvent1.java".

I think that in the name of cross platform build compatibility and
developer sanity, there is no reason to name events like this even if
it might actually succeed in building on a Unix system.

Now, the case where custom events exist in one package with the
same class names as events stored in other package is certainly
possible. However, again, if you are actively specifying that event to be
registered, the voices in your head should start warning you about the
obvious issues you are creating for yourself.

Christian (or anyone else with an opinion), is there any way to
prevent the issue that James brings up here?  If there isn't, has it
ever even been an issue for you?  I know it hasn't for me...yet...but
we should think ahead to prevent future problems.

Jake

JG> Later,

JG> James Graves, CTO
JG> Delta Mobile Software                           http://www.deltamobile.com
JG> _______________________________________________
JG> Barracuda mailing list
JG> [email protected]
JG> http://www.enhydra.org/mailman/listinfo.cgi/barracuda
JG> FAQ - http://www.jguru.com/faq/Barracuda



-- 
Best regards,
 Jacob                            mailto:[email protected]

_______________________________________________
Barracuda mailing list
[email protected]
http://www.enhydra.org/mailman/listinfo.cgi/barracuda
FAQ - http://www.jguru.com/faq/Barracuda