Hi, I too like the idea of a configuration point for the substitutions. I can't see a way to convert the name into something more simple, without the risk of getting collisions and/or somewhat ugly URLs.
With a configuration point one will be able to; * Get the abbreviation of the entity class to be as small as a single character * Have no collisions * Rename an entity without problems * "Force"/entices us to configure our own abbreviations, which is good because otherwise there could be trouble when renaming entities. 2006/6/6, Andreas Andreou <[EMAIL PROTECTED]>:
James Carman wrote: > Actually, I like Adreas Androu's idea. He said (from the developers list): > > "I think I would use the entire entity name enhanced with an optional > properties file that would allow users to define substitutions." > > However, I'm going to go one better. Instead of using a properties file, > I'll create a configuration point for the overrides. That's the "HiveMind > Way." > hehe! Actually I initially meant to write: "I think I would use the entire entity name enhanced with substitutions" feeling that you'll make out the missing parts > When I said "use the hashCode()", I meant to use the hashCode() of the > entity name (a String) itself, not of the entity. > > -----Original Message----- > From: Andreas Bulling [mailto:[EMAIL PROTECTED] On Behalf Of > Andreas Bulling > Sent: Tuesday, June 06, 2006 8:24 AM > To: Tapestry users > Subject: Re: Tapernate Squeezer... > > Hi James, > > I'd vote for the hashCode() approach, why: > > 1) It's the approach already used and widely accepted (for example > in Hibernate) > > 2) using Hibernate (which is what Tapernate is dedicated to) you > are advised to implement hashCode() and equals() anyway (according > to the Hibernate homepage) so it's no additional expense to use > it for Tapernate. > > Just my two cents... > Andreas > > On 06. Jun 2006 - 08:08:21, James Carman wrote: > | For those of you who are using Tapernate (and those of you who have done > | something similar in the past), I have a question for you. Currently, the > | Tapernate entity squeezer uses an abbreviation for the class name > (basically > | an integer). However, I was thinking that this might not be a good thing > | for external links. What would happen if the application is restarted and > | someone has bookmarked an external link? So, I need to come up with a > | reliable/repeatable way to "shrink" the entity name down to a small > string. > | Now, the situation gets even trickier when you consider the fact that your > | application may add entity classes between releases. Therefore, I can't > | just sort the entity class names and then assign them a number (their > index > | in a list). I *really* don't want the entire entity name in the URLs. > That > | would look kind of cheesy. The way I see it, there are some options... > | > | 1. Use a message digest of the entity name. The message digests would > all > | be the same length, so we wouldn't have to worry about the URLs "growing" > | when the entity name grew. But, there *is* the chance for digest > collisions > | (digest of entity name A is the same as digest of entity name B). > | > | 2. Use the hashCode() of the entity name Strings. Again, we've got the > | possibility for collisions. > | > | 3. Just use the "simple" entity name (the part of the name after the last > | '.'). I don't think Hibernate requires that you have unique "simple" > names > | for your entity classes. In practice, this is typically not a problem. > | But, in general, it's not a robust solution. > | > | 4. Just use the entire entity name and don't worry about all of this! > | Users can override it if they wish and how they wish. > | > | I will be creating a service point which does the translation to/from the > | entity name abbreviation and users can override it if they want. Which of > | these (or if you have other ideas) would be the best "default", though? > The > | entity squeezer will detect when there is a collision and either throw an > | exception or print an error message to the logs (haven't decided yet) to > let > | you know that you need to come up with a better solution for entity name > | abbreviation. > | > | James > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- ted --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
