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]

Reply via email to