You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by James Carman <ja...@carmanconsulting.com> on 2006/06/06 14:06:31 UTC
Tapernate Squeezer...
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapernate Squeezer...
Posted by Andreas Andreou <an...@di.uoa.gr>.
I think i would use the entire entity name enhanced with an
optional properties file that would allow users to define substitutions.
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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Tapernate Squeezer...
Posted by James Carman <ja...@carmanconsulting.com>.
Sorry, this was supposed to go to the users, but you guys should be able to
give me some advice.
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Tuesday, June 06, 2006 8:07 AM
To: 'Tapestry development'
Subject: Tapernate Squeezer...
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org