The Tapernate entity squeezer has now been updated to include the aforementioned changes. The documentation (www.carmanconsulting.com/tapernate) has been updated to reflect the new configuration options available for the squeezer. Enjoy!
James -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 06, 2006 7:52 PM To: 'Tapestry users' Subject: RE: Tapernate Squeezer... That's the way I went with it. I also made a configurable option (set via a FactoryDefault symbol) that will allow you to tell it whether or not to use the "short name" of the classes or not. The default is to use the short name. -----Original Message----- From: Ted Steen [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 06, 2006 7:42 PM To: Tapestry users Subject: Re: Tapernate Squeezer... 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] --------------------------------------------------------------------- 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]
